NPO lost bug op in iOS-versie van Luister-app die voor hoog dataverbruik zorgde

De NPO heeft donderdagavond de bug gepatcht in de iOS-versie van de Luister-app die voor een zeer hoog dataverbruik zorgde. Door de bug downloadde de app regelmatig een grote afbeelding, waardoor het dataverbruik opliep tot 50Mbit/s: ruim 150 keer meer dan gebruikelijk.

De 3.10.1-update is donderdagavond uitgebracht en 'optimaliseert het dataverbruik van de app'. De NPO bevestigt aan Tweakers dat deze update het probleem oplost en meldt dat het hoge dataverbruik 'mede werd veroorzaakt door het (continu) ophalen van afbeeldingen van de gedraaide muziek op de radiozenders'. "Hierbij werd door een bug ook steeds een grote afbeelding van het programma gedownload."

NPO's ontwikkelaars hadden de bug eerder op donderdag al verholpen, maar de update moest eerst door Apple gereviewd en goedgekeurd worden. Daarom hadden de ontwikkelaars intussen de afbeeldingen vervangen door geoptimaliseerde afbeeldingen, die voor minder dataverbruik moesten zorgen. De bug speelde niet bij de Android-versie van de app.

Het probleem met de iOS-versie van de NPO Luister-app werd donderdag bekend na een forumpost van Eppo ©. Door de bug varieerde het dataverbruik tussen de 7,2Mbit/s en de 47Mbit/s, terwijl bijvoorbeeld Spotify voor de hoogste kwaliteit 320Kbit/s vereist. Het dataverbruik leek dan ook meer op het verbruik van een 4k-streamingdienst. Onderzoek van laurens0619 wees al op de bug in de app die elke paar seconde een afbeelding van 3,5MB downloadt.

De bug is vooral nadelig voor mobiele klanten met een beperkte databundel en buitenbundelkosten. Deze klanten kunnen daardoor ongemerkt en onbedoeld aanzienlijk meer data verbruiken dan bedoeld, met hoge rekeningen tot gevolg. De bug zorgde bij Eppo © bijvoorbeeld voor buitenbundelkosten van 700 euro, waarna de simkaart door Simyo werd geblokkeerd. Providers willen in deze gevallen nog weleens coulanceregelingen toepassen, maar het is nog niet bekend of dat ook in dit geval is gebeurd.

Update, 18-08: Eppo © meldt dat Simyo als coulance de buitenbundelkosten terugbrengt tot 50 euro. Dit bedrag wordt door de NPO aan Eppo © vergoed.

Een foto van de NPO Luister-app zorgt vermoedelijk voor het hoge dataverbruik, via laurens0619.

Reacties (126)

[Blokker_1999]

Daarom hadden de ontwikkelaars intussen de afbeeldingen vervangen door geoptimaliseerde afbeeldingen, die voor minder dataverbruik moesten zorgen.

En dan stel ik me de vraag: waarom moet het tot zo een bug duren voordat ze dit doen? Dit is weer een typisch geval van: data is toch goedkoop, opslag is oneindig en de infra kan alles aan. Waarom zouden we er tijd in steken?

Ook bij ons in de firma zien we dat. Elke paar maanden mogen we enkele terabytes aan storage bijmeppen gewoon omdat iedereen er maar van uit gaat dat ruimte geen gebrek is. Niet voor de storage, niet voor het netwerk, niet voor de backups, niet voor ...

[Prince]

Volledig eens; mensen denken niet meer na.
- Grote ongeoptimaliseerde afbeeldingen sturen we maar door, "want het duurt toch maar een paar seconden om het te downloaden".
- Maar waarom telkens dezelfde afbeelding downloaden? Is caching op het device van reeds binnengehaalde media niet meer van deze tijd of zo; dit is vaak zelfs default ingebakken in de meeste modules die je gebruikt om data binnen te halen.
- Zelfs op vlak van compressie (denk aan deflate, gzip, zstd oid) wat dan weer extra servercapaciteit vereist en 'minder ecologisch is'.
* Soms staat dit aan voor jpg of andere niet comprimeerbare data - dit is gewoon dom.
* Soms doen ze dit voor bestanden kleiner dan 1380bytes; dat is ook niet slim - dit past sowieso in 1 netwerk package - geen nut om dit te comprimeren.
* Maar dan zie je ook soms dat dit soms niet aan staat voor txt, json, xml, html,... bestanden, wat weer zonde is van de bandbreedte. Zelfs gzip op niveau 3 zal ervoor zorgen dat je veel meer door je netwerkverbinding krijgt zonder je cpu zwaar te belasten. En een ietswat slim persoon zal zorgen dat de statische zaken op de reverse proxy gecached worden in gzip en/of zstd formaat.

Maar ik ben wellicht de oude developer die trots neemt in snelle en geoptimaliseerde code en een zo licht en optimaal gebruik van de infra. Want ja, wie wil er nu een vlotte gebruikerservaring die ook nog eens goedkoper is voor de firma zelf... (voel me oud :-))

[Exirion]

Ik voer altijd dezelfde strijd. Als je zelf ooit klokcycli hebt zitten tellen om loops op een 286 te optimaliseren, dan ben je een fossiel voor de mainstream developers die zich bijna nergens druk meer over maken als het om efficiency gaat. Of het nou om applicaties, backends, of firmware gaat, het is overal hetzelfde.

[Prince]

Pas op: als je zo een project van een jonge "developer" overneemt -omdat het productieverstorend traag is en je optimaliseert het, dan geloven ze je soms niet dat het doet wat het moet doen omdat het voor hen onbegrijpelijk snel is geworden. Dan zijn je geslaagde tests die je onderling afgesproken hebt, plots niet meer voldoende en willen ze nog weken schaduwdraaien.
Specifiek voorval: "oude app" was access (yes.. i know...) met allerhande handgeschreven importers, views op views - sommige zelfs nooit gebruikt, nergens indexen, slechte naamgeving die geen zin maakt whatsoever, etc... Dit ding draaide >24h voor een export en had geen multi-user ondersteuning.
Ik heb er een php/sqlite util van gemaakt, gezien ze reeds een servertje hadden waar php op draaide, en deze deet er ~100ms over voor een run.

Veel begint bij het architecturale van de app en heeft niets te maken met het ontwikkelen zelf. Gewoon goed boerenverstand...

[Exirion]

Veel begint bij het architecturale van de app en heeft niets te maken met het ontwikkelen zelf. Gewoon goed boerenverstand...

Is evident, maar da's weer een andere discussie

[LOTG]

Gelukkig staat het internet vol met dit soort inefficiënte code en suggereert AI ook vaak dit soort oplossingen, welke dan weer door onervaren developers word overgenomen en kunnen bedrijven roepen dat het ze zo veel minder tijd kost.

Ik ben in elk geval voorlopig nog wel van werk voorzien als ik de AI oplossingen zie die ik krijg voorgeschoteld door mensen die geen developer zijn en met AI een hele applicatie gemaakt hebben.

[mindcrimemike]

OMG ja! Moet wel zeggen dat leeftijd niet altijd een rol speelt. Heb begin jaren ‘90 als jonkie een Oracle query op Novell onder handen genomen van een senior met als resultaat dat de query die na 24 uur maar werd afgebroken er vervolgens ongeveer een seconde over deed. Niet zo gek want de Explain was van van anderhalf A4tje naar 5 regels teruggebracht. De Explain zei voldoende maar een collega is een week bezig geweest aan te tonen dat de nieuwe query feilloos was terwijl de query zelf echt goed te lezen was: het was simpelweg onvoorstelbaar. Kers op de taart was dat de hardware boer helemaal door het lint ging omdat hij een order voor een machine met krankzinnig veel geheugen voor die tijd verloren zag gaan. En dat voor een aantal provincies waar de software voor werd ontwikkeld :-)

[readefries]

Zelfs zoiets simpels als 'If-Modified-Since' headers ondersteunen is vaak al te veel moeite, terwijl dat veel libs dit gewoon ondersteunen :/

[YGDRASSIL]

Ik voer ook dat achterhoedegevecht. Een boolean als string 'JA' of 'NEE' in de database gooien. Voor elk AI model een conda instance spawnen (en meerdere parallel) , flink wat db queries doen daarin en het vervolgens niet consistent en snel genoeg krijgen. 'Server heeft meer geheugen en cpu nodig'. Heb het maar opgegeven. Is meer tools chainen in scripts dan serieus programmeren tegenwoordig.

[danmark_ori]

Je hebt al +2 beoordeling 'dus het doet er niet meer toe' en toch: wat je zegt is me echt uit het hart gegrepen.

[Robbierut4]

Je stelt de vraag maar geeft zelf het antwoord al. Data is goedkoop. Opslag is ook goedkoop.

Mensen daarentegen zijn duur.


Als bedrijf kun je je geld maar 1 keer uitgeven. Dus waarom kostbare arbeidstijd verliezen aan optimalisatie, als je voor minder geld er een extra HDD in drukt?

[swhnld]

Tsja, dat is de denkfout die veel mensen onwetend maken. Je drukt er toch een harddisk bij, die koop je voor een paar tientjes bij Ali.

Echter bij een bedrijf met enterprise raid oplossingen, backup tapes, etc. is het niet een kwestie van 1 losse harde schijf, maar zitten die in kabinetten, serverkasten, verbruiken constant stroom, data moet veilig gesteld worden op backup tapes, die tapes moeten binnen een bepaalde tijd hersteld kunnen worden om de RPO en RTO te garanderen en de diensten te kunnen leveren, die moet je ook testen dus opslag ruimte voor dat testen hebben, en ga zo maar door.

En dan is de vraag, is dat eenmalige uurloon van optimalisatie het waard tegen de eenmalige en terugkerende kosten van die extra opslag?

En in het geval van de NPO app, de NPO zal een verbinding hebben waarop zij de data uitzenden, en als hun verbruik omhoog schiet zullen zij ook meer bandbreedte nodig hebben, dus in dit geval snijd het mes aan twee kanten, waarbij zowel de kosten voor de klant (databundels) als voor de NPO (bandbreedte) omhoog vlogen. En dan heb ik het nog niet over kosten van de schade aan de reputatie van de NPO. Het vertrouwen is geschaad en er zullen gebruikers hierdoor afhaken.

[T-men]

En in het geval van de NPO app, de NPO zal een verbinding hebben waarop zij de data uitzenden, en als hun verbruik omhoog schiet zullen zij ook meer bandbreedte nodig hebben, (...) Het vertrouwen is geschaad en er zullen gebruikers hierdoor afhaken.

Kom op zeg.... wat is er nou gebeurd ?

Er is een app ontwikkeld. Requirement was blijkbaar dat daarin een actueel plaatje te zien was. Dat is geïmplementeerd en werkte in de ontwikkelomgeving, de testomgeving en in de acceptatieomgeving perfect.
Echter per ongeluk is het plaatje een versie met een hoge resoluutie geworden en daardoor 3,5 MB groot.
Dat valt in de paar (t.o.v. een productie-load) testjes die gedraaid worden alleen op als je daar specifiek naar kijkt en dat doe je alleen als je daar risico's verwacht. Met de kennis achteraf had je dat anders gewild, maar blijkbaar is dat vooraf niet als risico gezen.

De migitation is geweest om het hi-res plaatje te vervangen door een low-res plaatje. Vervolgens is de echte oplossing geweest (aanname !) om het low-res plaatje voortaan te cachen.

Probleem opgelost.

Is het een fout geweest ? Ja.
Is het echt een blunder ? Nee, zo zou ik het niet willen noemen. Het had ons allemaal kunnen overkomen, denk ik.

[Monzo]

Het gesprek hier gaat niet om het plaatje maar om het feit dat de requirements niet letten op netwerk, opslag, backup en andere infrastuctuur-zaken.

Dit antwoord geeft precies het probleem aan waar ‘oudjes’ zoals ik tegenaan lopen.

De kwaliteit en kunde wat betreft opletten op onderliggende requirements is aantoonbaar dramatisch laag tegenwoordig.

[laurens0619]

Wat er in dit geval gebeurd is weet ik natuurlijk niet.

Maar in zijn algemeenheid zie ik met low-code/no-code (al dan niet AI) wel een verschuiving van totaalplaatje naar vooral functionaliteit.

Ik merk het ook als ik zelf iets schrijf in code of in PowerAutomate. Bij de laatste gaat het echt om functionaliteit en heb je of geen last van inefficiente code of je hebt er niet eens duidelijk zicht op water er onderwater allemaal gebeurd.

Nogmaals voor dit incident geen idee wat de oorzaak is maar ik denk dat we met AI/citizen development wel meer van dit type incidenten kunnen gaan meemaken. Tenzij de AI weer slim genoeg gaat worden om onderwater ook naar efficientie te kijken.

[Robbierut4]

Tsja, dat is de denkfout die veel mensen onwetend maken. Je drukt er toch een harddisk bij, die koop je voor een paar tientjes bij Ali.

Echter bij een bedrijf met enterprise raid oplossingen, backup tapes, etc. is het niet een kwestie van 1 losse harde schijf, maar zitten die in kabinetten, serverkasten, verbruiken constant stroom, data moet veilig gesteld worden op backup tapes, die tapes moeten binnen een bepaalde tijd hersteld kunnen worden om de RPO en RTO te garanderen en de diensten te kunnen leveren, die moet je ook testen dus opslag ruimte voor dat testen hebben, en ga zo maar door.

En dan is de vraag, is dat eenmalige uurloon van optimalisatie het waard tegen de eenmalige en terugkerende kosten van die extra opslag?

Juist met zo'n robuust systeem is wat extra opslag niet zo duur. En laten we wel wezen, het gaat hier om een foto van 3.5MB. Nog nieteens een afrondingsfout in de goedkoopste consumenten laptops, laat staan in een bedrijf.

En dan heb ik het nog niet over kosten van de schade aan de reputatie van de NPO. Het vertrouwen is geschaad en er zullen gebruikers hierdoor afhaken.

Dit is wel heel overdreven hoor. Ja, het is nogal balen voor de getroffen consumenten. Maar als elke bug en elk software probleem ervoor zorgt dat gebruikers afhaken dan had geen enkel bedrijf nog gebruikers/klanten.

[mcmd]

Het kan toch ook allebei? Een mens kan zich buigen over de procedure, dit optimaliseren (ook wat betreft data/opslag gebruik) en daarna tot in de lengte van jaren toepassen en geld besparen in de uitvoeringskosten?

[lenwar]

Ik ben het met je eens hoor, maar zie het zo.

Een persoon kost 100 euro per uur. 1 terabyte aan opslag nog geen 100 euro per jaar. Als je een persoon er meer dan een uur ermee bezig is per jaar, had je beter 1TB erbij kunnen kopen, en heeft die persoon ook nog aan wat anders kunnen werken.

[!mark]

De daadwerkelijke kosten zitten hier natuurlijk vooral in het onnodige dataverkeer, niet zozeer de opslag van een foto van 3.5MB

Als je naar iedereen die deze app gebruikt 24GB per uur moet sturen, i.p.v. de gebruikelijk ~50-120MB voor een audio app dat zijn dit echt serieuze kosten welke heel snel gaan oplopen hoor. Stel dat er dagelijks 10k mensen één uur naar luisteren, dat is dat al 240TB aan dataverkeer terwijl het iets van 850GB had moeten zijn, en dat elke dag weer. Dat gaat ook voor een bedrijf om serieuze bedragen die een stuk hoger liggen dan eenmalig paar uur aan salaris hoor.

Als dit niet uit zou maken dan zou een bedrijf als Netflix immers ook gewoon UHD-BD kwaliteit kunnen aanbieden, maar die steken er behoorlijk wat moeite in om de videostream zou klein mogelijk te bouwen mede door gebruik van de nieuwste codecs.

[Reactie gewijzigd door !mark op 8 augustus 2025 12:39]

[laptopleon]

Precies en we focussen nu op meer data / netwerk activiteit, maar het kost ook meer accu-lading. En in dit geval is het streaming dus die data wordt (misschien) niet lang bewaard, maar ik zie bij zoveel mensen de mailboxen jaar na jaar mails opstapelen, met soms tientallen MB’s aan foto’s en andere bijlagen. Dat moet uiteindelijk ergens bewaard worden en dan zijn er nog backups.

Grotere harde schijven, grotere ssd’s in telefoons etc kosten ook meer energie en grondstoffen om te maken. Netwerken gebruiken meer energie als ze meer rond moeten pompen.

[lenwar]

Uiteraard. Het verschilt per situatie. In dit draadje ging het specifiek over opslag.

Ik ga er met redelijke zekerheid vanuit dat bedrijven prima de afweging kunnen maken tussen kosten van optimaliseren en risicos/onderhoud van die optimalisaties ten opzichte van slaafs capaciteit blijven bijkopen.

Het is niet voor niets dat Netflix en co relatief zwakke bandbreedtes leveren, en dat Microsoft 6TB opslag voor 130 euro per jaar aanbiedt (inclusief Office). Beide bedrijven hebben prima door hoe ze dit optimaal moeten doen voor zichzelf en hun klanten.

In dit draadje ging het dus over het iedere keer maar meer opslag kopen in plaats van optimaliseren binnen een bedrijf.

[Jacques-Oh]

Oprechte vraag, maar gaat het om zoveel kosten? Ik ga er dan ff vanuit dat een bedrijf geen ‘unlimited data’ abonnement kan hebben, maar is dat verkeer zo duur?

[moimeme]

Was het zo eenvoudig in een bedrijf!

Backup en archievering zullen ook langer duren en meer ruimte kosten, evt terug zetten ook. Idem dito voor de netwerk activiteit.

Dat is een afweging die moet gedaan worden en niet zo simpel is.

[Reactie gewijzigd door moimeme op 8 augustus 2025 17:36]

[lenwar]

En ook dat verschilt weer per situatie. Als die opslag de archivering/back-up is, dan is dat dus niet van toepassing (hooguit voor het terughalen).

En als de backups met snapshots worden gedaan, heb je al helemaal geen (noemenswaardige) back-up-tijd/restoretijd. (Je kunt de back-up van gisteren zogezegd)

Als je alles drievoudig opslaat is herstel bij een fysieke calamiteit geen probleem. Als je data transactionele data is, maakt het herstel ook niet meer uit (qua snelheid). (Transacties terugdraaien)

En al het bovenstaande is niet voor alles van toepassing, en zal dus zelfs per applicatie/systeem verschillen. Dus bij iedere situatie zal het bedrijf andere afwegingen maken.

Maar in de basis is opslag zo goedkoop, dat het ‘besparen op opslagvolume’ vaak niet rendabel is, tenzij je inderdaad heel specifieke herstellingen moet hebben en het echt niet anders kan dan met een back-up herstellen.

[moimeme]

Ja, iedereen bedrijfsoort is anders.

Vaak zijn backup en archievering apart procedures, de data is deel transactioneel, deel niet.

En soms moet, wettelijk, contractueel en van verzekeringseisen, een copie van de backup en archief op een bepaalde veilig plek!

[Reactie gewijzigd door moimeme op 12 augustus 2025 13:30]

[MenN]

Geen idee waarom je een nul mod krijgt, maar dit is wel echt de denkwijze die in de praktijk bij de mensen die besluiten nemen over dit soort dingen. Die weten ook wel dat het niet efficient of elegant is, maar mits er geen of nauwelijks impact is komt die 1TB er gewoon bij en werken we aan wat anders.

[T-men]

Ik denk dat er niet eens een denkwijze is. De meeste mensen hebben niet eens door wat hun data kost. Pas wanneer de schijf vol, of de bundel op is, dan merken ze pas wat er aan onzin over de lijn gegaan is.

Is dat dan laks van die mensen ? Nee ! Je merkt het gewoon niet. Het is net als pinnen vs. contant geld. Mensen die met cash werken hebben een veel beter besef van wat ze uitgeven. Pinners zien het vaak niet eens en geven daarom makkelijker onnodig geld uit.

[LOTG]

Omdat die development tijd geen recurring cost is, die opslag is dat wel. Tenminste ik zie niet veel scenario's waarin extra opslag nodig is voor een eenmalige release.

En meestal is dat ook een probleem wat zich opstapelt met verser ontwikkeling tot het op een gegeven moment gewoon niet meer vooruit te branden is. Kost meer opslag, dus waarschijnlijk ook meer ram en ook meer CPU.

Meestal stel je ook performance requirements, dat zorgt er voor dat men ook daadwerkelijk rekening houd er mee. Of je stelt onrealistische deadlines, en zit achteraf met slecht onderhoudbare software die niet performt.

[bewerkers]

Door te besparen op ontwikkeling, vooral architectuur voor het coderen en optimalisatie en refactoring na het coderen bouw je technical debt op. Uiteindelijk is de applicatie niet te onderhouden, buggy en traag. En dan moet het helemaal herschreven worden. Heb dat zo vaak zien gebeuren.

[Reactie gewijzigd door bewerkers op 11 augustus 2025 08:49]

[HansvDr]

Ik vraag me af, waarom moet er überhaupt een plaatje van een dj getoond worden in een app die bedoeld is om te luisteren.

[YopY]

Om een illustratie te geven terwijl je door de app tikt.

[HansvDr]

Dus omdat je een DJ ziet besluit je om naar zijn programma te luisteren? Bijzonder

[R_Zwart]

Dat is toch niet zo heel raar? Jij hebt toch ook wel dingen waar je naar gaat kijken of het gaat lezen als er een plaatje bij staat ter indicatie? Bij vrijwel ieder tweakersartikel staan ook plaatjes om aan te geven waar het om gaat.

[HansvDr]

Als ik de foto van desbetreffende dj zie zegt dat helemaal niets over wat er voor programma te beluisteren is. Het logo van Radio 2 zegt net zo veel als er dan toch een plaatje bij moet.

Jou commentaar heeft een standaard icoontje als plaatje, toch lees ik het :-)

[PCG2020]

De app ontvangt niet alleen een plaatje van de presentator, c.q. het programma, maar bijvoorbeeld ook van de hoes van de plaat waar een liedje van gedraaid wordt. Maar ja, als dat elke seconde gebeurt en in hoge resolutie, dan gaat dat qua data wel hard oplopen natuurlijk.

[_Pussycat_]

Het is standaard dat bij een onderwerp een plaatje moet.

Een nu.nl (of willekeurige andere website) zal altijd bij ieder artikel een plaatje hebben; bijvoorbeeld bij een artikel over de problemen met plastic staat daadwerkelijk een foto van een plastic boodschappentas. Ja, ik wist al hoe die er uit zien...

[3raser]

Ik vermoed (pure gok) dat deze afbeelding automatisch geschaald wordt naar aanleiding van het verzoek. In dit geval is het verzoek "width=auto" maar dat zou mogelijk ook "width=1024" kunnen zijn wat leidt tot een veel kleinere afbeelding en dus minder dataverkeer. De bronfoto moet dan echter wel zo groot mogelijk zijn zodat je deze op zoveel mogelijk resoluties kunt schalen. Ze hebben nu de bronfoto waarschijnlijk aangepast door een kleinere variant in een lagere resolutie zodat ook iedereen die "width=auto" gebruikt een kleine afbeelding download. Ik neem aan dat ze dat bedoelen met een geoptimaliseerde afbeelding.

[johnny2000]

Deze reactie gemint? Lijkt mij zeker een plausible actie. Wellicht ook nog specifiek op UA (dus iOS only).

[_Pussycat_]

"auto" was misschien wel passend zijn om 1x op te halen (en dan misschien altijd bij deze DJ getoond te worden); het is dan alleen een probleem als het 1x per seconde gebeurt.

[Heaget]

Ik zie dit op meer vlakken terug. Waar voorheen nog veel aan optimalisatie werd gedaan is dat nu eigenlijk verleden tijd of iets wat "in de toekomst altijd nog kan". Dan gaat het over data, maar ook over gebruik van alle andere resources.

[YopY]

Normaliter (of, zou ik doen) pleur je je afbeeldingen in een CMS, en die zorgt er dan voor dat de afbeeldingen geresized worden. De bug kan in dit geval zijn dat ze vanuit de app niet een parameter voor de gewenste resolutie meegeven.

Dat is tegenwoordig wat ingewikkelder dan vroeger, de apparaten waar deze app op draaien hebben nl vele verschillende resoluties, waardoor je een 1x, 2x (retina) of 4x (tablet) afbeelding moet kunnen opvragen of moet meeleveren met je app. Bij het laatste zal de app store (ik weet alleen hoe het bij apple werkt) aparte bundels met assets genereren afhankelijk van op welk apparaat de app gedownload wordt.

[W00fer]

Dit is hetzelfde met waarom apps 10mb waren en nu 1GB. Er is geen optimalisatie meer. Je moet maar een nieuwe mobiel kopen. Zelfs de Lite versie van apps is al gigantisch geworden.

[Prince]

Een deel hiervan is wel te verklaren. De resource-pack van een apk moet splashscreens en logo's bevatten per resolutie of beeldverhouding. Dit is erg veel herzelfde logo dat herhaald wordt. Het is spijtig dat Android niet ondersteunt (tot zover ik weet - ik maak eigenlijk geen mobiele apps) om tijdens de install of eerste start de high quality resources te hercomprimeren en resizen naar de gewenste resolutie. Dit kan in een app al gemakkelijk 100(den) MB's uitmaken.
Niet alles ligt dus bij de developer.

[Falcon]

Dat is tegenwoordig met bijvoorbeeld Scalable Vector Graphics (SVG) technologie ook geen excuus meer.

En dan doel ik op jouw "per reso en beeldverhouding".

[Reactie gewijzigd door Falcon op 11 augustus 2025 13:28]

[Prince]

Als ik me niet vergis, moet dit bestand op meerdere locaties opgeslagen worden. Elke locatie is dan een bepaalde resolutie. Dus zelfs met svg, moet dit bestand meermaals opgeslagen worden.

Ik vind dat "niet van deze tijd". Zelfs al zou je een jpg meegeven, dan zou bij een installatie gewoon moeten geresized worden (naar mijn bescheiden mening)

[jmvdkolk]

Misschien hebben die mensen waarmee jij samenwerkt wel een heel ander perspectief.

Ik heb heel veel discussies gehad met mijn IT afdeling over storage. Storage is natuurlijk niet gratis en ook niet goedkoop. Maar er zijn toepassingen die veel data verwerken en die data moet ergens staan. Bij ons gaat het om test data voor ons software product. Een gemiddelde klant verwerkt per dag zo'n 2 TB aan data met ons product, en dit groeit zo'n 10% per jaar. Iedere keer als wij een unieke set kunnen krijgen voor onze ontwikkeling, moeten we zo'n set data van een dag kwijt. We ruimen ook regelmatig oude sets op, maar gemiddeld groeit het flink. Onze IT afdeling vindt dat wij absurde hoeveelheden data nodig hebben en we moeten structureel escaleren om te zorgen dat er voldoende ruimte beschikbaar gesteld wordt. En ja, dit heeft overal impact, inclusief pijn in de backups. Wij zijn een software bedrijf. We kunnen ook stoppen met ontwikkeling voor onze klanten, of minder kwaliteit gaan leveren, en dan hebben we uiteindelijk geen baan meer omdat we weg geconcurreerd worden.

Kortom, misschien is het perspectief van de vragers wel anders.

[kh65]

Overigens vind ik een afbeelding van 3,5MB voor een webtoepassing ook belachelijk groot.

De gemiddelde full-RES foto uit een iPhone camera haalt dat niet eens

[-Colossalman-]

Dit klinkt ook meer dat de originele foto gebruikt is ipv een gecomprimeerd bestand voor de app.

[Tuktop]

In de metadata is te zien dat het gaat om een 35MP-foto uit een Sony ILCE-7M4K. Die maakt RAW-opnames van 60-120 MB. De originele foto is het dus niet geweest, maar wel een full res JPG, geëxporteerd door Lightroom (met gelukkig nog best aardige compressie, want anders was de omvang van dit probleem nóg groter geweest).

[PolarBear]

Weet het niet hoor maar een gemiddelde hires foto op mijn iPhone 16 pro kan makkelijk 4-5 MB zijn tot we 11 MB. En dat zijn dan nog jpegs.

[g_v_rijn]

Apple's 'standaard' back-up instelling staat zodanig ingesteld dat 'alles' (ook Apps data van derden welke een zelfstandige back-up functie hebben, denk aan Google Chrome, Drive, Foto's, gMail, OneDrive, Edge, ect) onnodig worden geback-upt naar jouw iCloud. Apple lacht in zijn vuistjes - iCloud is een prima money maker. De Apple gebruiker niet meer zelf nadenkt - kritisch kijkt naar nut en noodzaak. Gezien de - nu nog - lage kosten van data opslag - begrijpelijk.

[Reactie gewijzigd door g_v_rijn op 8 augustus 2025 12:01]

[AW_Bos]

Waarom zou Simyo een SIM-kaart blokkeren, en niet het dataverbruik?

De bug zorgde bij Eppo © bijvoorbeeld voor buitenbundelkosten van 700 euro, waarna de simkaart door Simyo werd geblokkeerd.

[rvdvelden]

Waarschijnlijk omdat dit zodanig verdacht is qua kosten, dat ze een vermoeden van fraude hebben en uit voorzorg dus de hele kaart maar blokkeren?

[AW_Bos]

Misschien ben ik wel een pietje precies, maar de terminologie bij Simyo over een 'simkaart blokkade' klopt niet. Want enkel uitgaand verkeer wordt geblokkeerd, en dat gebeurt gewoon op de backend-systemen van ze. Als een simkaart geblokkeerd wordt, dan is er sprake van dat deze niet meer verbinding met het netwerk kan maken.

Noem het dan gewoon een data-blokkade ofzo. ;)

[laptopleon]

Ik snap wat je bedoelt, maar ook ‘data-blokkade’ dekt de lading niet helemaal. Ik maak me tegenwoordig minder druk om imperfecte omschrijvingen, zolang maar duidelijk is wat er bedoeld wordt. Ja, enerzijds niet altijd een goed excuus, maar als je alles perfect zou verwoorden, heb je ook veel meer verschillende woorden veel meer tekst en dus meer tijd nodig, ook om alles te lezen.

Nederlands is dan vaak nog niet eens zo gek in vergelijking met (Amerikaans) Engels, waar het vaak zo versimpeld wordt dat het ronduit verwarrend wordt. Een new york pizza kan bijvoorbeeld een bepaalde variant pizza zijn maar ook een vestiging van een keten pizzeria’s die New York Pizza heet.

[AW_Bos]

Net als SMS-bom, wat verkeerd gebruikt wordt. In plaats van bulk-sms te sturen naar mensen die op een bepaalde plek van misdaad aanwezig waren, noemen ze dat nu SMS-bom.

[Tuktop]

Omdat je feitelijk een (te) hoge schuld opbouwt en ze eerst een aanbetaling willen zien voordat ze hun dienstverlening aan je hervatten.

Je Simyo simkaart wordt geblokkeerd als ons systeem constateert dat je meer dan € 100,- per 24 uur of meer dan € 250,- per week buiten je bundels hebt verbruikt. Dat is om onverwachte hoge kosten te voorkomen. Je kunt je simkaart weer activeren door een tussentijdse betaling te doen.

[AW_Bos]

True, maar dan is de omschrijving fout.

Met een SIM-kaart blokkade wordt gesuggereerd dat de simkaart zelf niet meer geaccepteerd wordt door het netwerk.

[Reactie gewijzigd door AW_Bos op 8 augustus 2025 10:07]

[Tuktop]

Eens hoor. Al wordt er nergens gezegd om wélke 'onverwachte hoge kosten' het gaat: voor de consument of voor Simyo zelf

[Raymond Deen]

Dan zijn ze na €700 rijkelijk laat met blokkeren….
Wat een bedrag zeg! Bent weer herinneringen naar boven aan vroeger toen in het buitenland nog zo afschuwelijk duur was.

[Tuktop]

Klopt, daar zijn ze erg laat mee. Naar eigen zeggen doordat de verbruiksdata niet realtime binnenkomt. Of dat klopt, weet ik niet.

[Raymond Deen]

Dat is dan volgens het berichtje dat ik een paar posts terug zag bijna na drie weken!
Dat is wel heel erg niet realtime🤣

[AnonymousGerbil]

Of dat klopt, weet ik niet.

Kan natuurlijk prima kloppen dat ze hun infrastructuur zo hebben ingericht.

Dat rekeningen dan zo hoog op kunnen lopen is natuurlijk puur toeval /s

[watercoolertje]

Dat leggen ze uit in smsjes waarvan screenshots in het gelinkte forumtopic te vinden zijn

[Reactie gewijzigd door watercoolertje op 8 augustus 2025 09:38]

[nasdude]

Waarom moet je 50 cent per maand bijbetalen voor een dataplafond zodat je niet door je bundel heen gaat, en waarom laten ze die rekening dan doorlopen tot 700 euro? Beetje schofterig, dit was altijd maximaal 50 euro (of was dat alleen tijdens roaming?)

[Groentjuh]

Europese roam-like-home wetgeving regelt die 50 (ex BTW) limiet. Voor Nederlandse providers is dat dan ook 60,50 voordat je geblokkeerd wordt. Echter is dat dus alleen voor tijdens roaming.

Die wetgeving is echter wel zodanig geschreven dat het interne markt niet beïnvloed. Op die wijze heb je nu ook dat bellen vanuit Nederland naar België buiten een bundel valt, terwijl bellen vanuit Duitsland naar datzelfde Belgische nummer binnen de bundel valt.

[Reactie gewijzigd door Groentjuh op 8 augustus 2025 10:20]

[GertMenkel]

Omdat ze lekker cashen op de klanten die per ongeluk 100 euro betalen. Als de prijs heel hoog wordt, stijgt de kans dat de klant helemaal niet betaalt, dan kun je ze beter afstoten.

Simyo en de andere euroknallers moeten ergens hun geld verdienen om de prijzen laag te houden.

[berkie89]

Daar is iemand lekker aan het vibe coding geweest .

Maar met een meer serieuzere noot: €700,- aan kosten door een buggy app vind ik toch wel erg zorgelijk. Iemand met een krappe beurs kan zo toch flink in de schulden komen. Zeer slecht van de NPO dat een bug als deze niet gevonden is tijdens het testen, maar minstens net zo slecht dat Simyo de buiten bundel kosten zo hoog laat oplopen.

[CPV]

Bij Symio heb je de keuze: een datalimiet instellen of gewoon doorgaan.

[DonJunior]

sidenote: je moet wel betalen voor het instellen van een datalimiet. Het is maar 50 cent. Maar het feit dat ze dit een betaalde feature maken vind ik persoonlijk echt absurd.

Bij andere providers kun je het gewoon instellen dat buiten de bundel het verbruik geknepen wordt en indien het verbruik dan boven een bepaalde drempelwaarde komt het internet volledig afgesloten wordt.

[Visgek82]

Bij android is het gewoon gratis in te stellen (hardwarematig) op je telefoon. heb je niks voor te zoeken bij je provider.

[DonJunior]

Dat weet ik. Heb zelf al jaren android. Punt is meer dat andere providers het gewoon als gratis dienst beschikbaar stellen en het bij Simyo geld moet kosten. Dat begrijp ik gewoon niet.

[Visgek82]

Bij Lebara ook. Maar dat is de prijs die je betaald bij de prijsvechters.

[CPV]

Vind ik wel redelijk: ik hoef niet mee te betalen aan features, die ik niet gebruik.

[GertMenkel]

iOS heeft dat helaas niet. Apple zal wel aannemen dat als je een iPhone kunt betalen, je ook onbeperkt internet kunt betalen ofzo.

Op Android gelukkig geen probleem, daar zit het al tien jaar in.

[pbk]

Wat apart dat iOS die mogelijkheid niet biedt, Lijkt me een heel basale functie. Hier thuis hebben we alleen Android telefoons en dat wordt altijd direct ingesteld om onverwachte kosten te voorkomen als er een nieuwe telefoon wordt aangeschaft of als de databundel wordt gewijzigd.

[xFeverr]

Dat zie je vaak. De goedkopere aanbieders bieden zo'n gratis service niet aan of niet meer aan. Bij Simpel was het prijsplafond ook eerst gratis, en nu niet meer. En het geld pas vanaf 10 euro.

Tsja, KPN is dan bijvoorbeeld wat duurder. Maar daar kun je geen extra kosten krijgen als je over je databundel heen gaat. Ze schroeven je snelheid behoorlijk terug, maar je blijft online zonder schandalig hoge rekening.

[Tc99m]

Maar het feit dat ze dit een betaalde feature maken vind ik persoonlijk echt absurd.

Dan kies je een provider die wél standaard een dataplafond heeft. Simyo is een budgetprovider, dus ook een budgetproduct, waar alles dat extra is meer kost.

Ik zit zelf bij Youfone, daar kost een dataplafond ook extra, maar wordt het ook duidelijk aangegeven dat je zonder plafond buiten je bundel kunt gaan. Je maakt dan zelf de afweging.

[Reactie gewijzigd door Tc99m op 8 augustus 2025 10:32]

[Alex3]

Ik heb mijn telefoon ingesteld me te waarschuwen als ik nog 2 GB over heb.

[WhatsMyUsername]

Vreemd dat het 700 euro zou zijn, het is wettelijk zo geregeld dat je buitenbundelkosten beperkt is tot 60.50 euro per maand.

[aap]

Ik hoorde net op het Radio 2 nieuws dat het Tweakers artikel daar inmiddels ook bekend is.

[laurens0619]

Interessant om de response van de NPO te lezen dat mijn hypothese klopte van de afbeelding die te vaak/groot werd ingeladen

Wel een goede wake up call mbt datalimieten.
Simyo stuurt een SMS bij 80% en 100% van het bereiken van je bundel. Echter kan hier een vertraging in zitten

In Nederland wordt het verbruik normaal tot 4 uur vertraagd bijgewerkt en in het buitenland tot 36 uur. Daarom kunnen we niet garanderen dat je aansluiting precies op het moment van bovengenoemde grenzen (€ 100,- of € 250,-) geblokkeerd wordt. Je bent de gemaakte kosten boven deze grenzen wel verschuldigd aan Simyo


Simyo biedt een verbinding van maximaal 300mbit down en 150mbit up.
Na 4 uur 300mbit zit je op 540GB * 0.15/mb == 82.944 euro
Na 36 uur 300mbit zit je op 4860GB * 0.15/mb = 746.496 euro

Dit zijn natuurlijke theorische maximum getallen maar ik vind het wel zorgelijk.

[Reactie gewijzigd door laurens0619 op 8 augustus 2025 11:11]

[m_snel]

Ik had ooit binnen enkele dagen een rekening van T-mobile toen die net begonnen met internet bundels . Toevallig ook voor het luisteren naar streaming audio via internet.

Bleek dat je de bundel apart moest activeren, wat nergens vermeld was.

Nu was het verder technisch onmogelijk om de maandelijkse bundel in een paar dagen leeg te trekken, aangezien je toen nog een verbinding had van kilobits.

Ik eerste instantie probeerde ze natuurlijk er onder uit te komen , maar om de technische beperkingen konden ze toch niet heen en kreeg ik netjes een creditnota. En vertelde hoe je die bundel moest activeren.

Maar het is wel iets om even op te letten.

[Davey400]

Het zou heel netjes zijn van de NPO als deze @Eppo © schadeloos stellen als dank voor het tijdig melden van het probleem en zelfs de oorzaak te achterhalen; dat heeft sowieso een hoop diagnose gescheeld, die weer niet aan dure consultancy-uren hoeven te worden besteed.

[nnndoh]

Sinds je een account moet hebben , heb ik de app eraf gegooid

[Oeroeg]

https://podcast.npo.nl/

Gelukkig is er vooralsnog vrije keuze om een andere cliënt te gebruiken.

[dingezzz]

Misschien loop ik nog achter in mijn luister app, maar ik kan gewoon alles luisteren zonder account.

[RonnieKo]

Sinds wanneer moet jeen account hebben? Ik luister nog steeds zonder account. Het is echt niet nodig. Je krijgt alleen constant de vraag of je een account wil. Net als bij alle andere websites die graag zien dat je een account neemt.

[nnndoh]

radio2 app zodra je de studio wilt appen

[RonnieKo]

Ik wil niet appen met de studio .... alleen radio luisteren En dan heb je geen account nodig voor de app NPO Luister.

[Otto Jans]

Dit zijn van die bugs waarvan ik denk, dit is zo slecht geprogrammeerd dat ze de mensen die hierdoor schade hebben geleden mogen gaan vergoeden.

[donkerlicht]

Ik vind dat wel wat gemakkelijk gezegd. Als gebruiker ben je verantwoordelijk wat er met je bundel gebeurt. Wanneer je geen unlimited abonnement lijkt het mij normaal dat je maatregelen neemt om het hoge verbruik te voorkomen. Dat kan enerzijds door een limiet in te stellen op je telefoon, maar veiliger is een dataplafond zoals in dit geval bij Simyo in te stellen. Bij het eerste heb je alsnog kans dat de telling van het toestel anders is dan bij de provider.

[cadsite]

Je mag van een gebruiker verwachten dat hij weet waar hij mee bezig is.

Eveneens mag je van een app verwachten dat die doet wat die moet doen.

De gebruiker gebruikt audio en verwacht, logischerwijs, dat die amper verbruikt.

Als een app dan het honderdvoud verbruikt kan je toch echt de schuld niet leggen bij de gebruiker.

[Tuktop]

Heel leuk en handig, zo'n datalimiet op je telefoon of een dataplafond, maar als je op dag 1 van je maandelijkse quotum door al je MB's vliegt door zo'n bug, dan heb je er weinig aan. Wat ga je de rest van de maand doen dan?

[RVervuurt]

Bijkopen? Da's het risico van een databundel natuurlijk, dat je die sneller gebruikt dan de maand duurt.

[Tuktop]

Tsja, dat risico is er inderdaad (en dat accepteer ik ook, omdat ik bespaar op maandelijkse kosten door geen onbeperkt abonnement te nemen), maar een app die ineens een factor 150 méér data verbruikt dan normaal door een bug, is toch niet echt een risico dat je kan (of zou moeten) incalculeren.

Ik vind dat de NPO hier best wel wat verantwoordelijkheid in kan nemen in de vorm van een financiële tegemoetkoming uit coulance. Althans, zo zou ik het oplossen als er iets vergelijkbaars zou voorvallen bij een dienst die we verlenen bij het bedrijf waar ik werk.

Maar goed, let's agree to disagree denk ik.

[RVervuurt]

Laten we eerst even kijken hoe Simyo het oplost. Kan goed zijn dat het allemaal wel meevalt.

Daarnaast is het risico er natuurlijk altijd, want elke app kan in principe zo'n bug bevatten.

[Tuktop]

Ik denk dat Simyo hier inderdaad best wel coulant mee om zal gaan, zeker als het bij deze gebruiker niet eerder is voorgekomen. Zo is dat in mijn ervaring (en bij een vriend) wel gegaan in elk geval.

Los daarvan: het feit dat het risico er altijd is voor de eindgebruiker (dat is onmiskenbaar), betekent m.i. niet dat de NPO in dit geval geen blaam treft. Ik vind het een blunder en ondanks dat het waarschijnlijk juridisch dichtgetimmerd is, zou ik het sjiek vinden van de NPO als ze coulant omgaan met dit soort gevallen als de ISP dat niet doet.

[donkerlicht]

Dan heb je pech voor de rest van de maand wanneer je niet meer dan je huidige bundel wilt verbruiken. Je voorkomt in ieder geval hogere kosten.

Overigens kan je vaak ook extra bundels bijkopen binnen de huidige maand of je bundel voor een maand ophogen. Dan kan je doorgaan met je mobiele internet. Of je gaat de rest van de maand alleen verder via wifiverbindingen.

[watercoolertje]

Dat is en blijft de keus van de gebruiker...

[Tuktop]

Het is niet de keus van de gebruiker dat een app die ze vaak gebruiken, door een bug ineens een factor 150 aan data verbruikt. Ik snap heus wel dat je als eindgebruiker een verantwoordelijkheid hebt over je beperkte databundel, maar het gemak waarmee men hier in de comments de NPO laat wegkomen, vind ik opmerkelijk.

[watercoolertje]

Dat van NPO is 100% belabbert, maar het is niet hun verantwoordelijkheid dat iemand anders in zijn bundel blijft.

[Tuktop]

Dat zeg ik ook niet.

Maar als ik een dienst lever (als zelfstandige én als het bedrijf waar ik in dienst ben) met een 100% belabberde fout, dan denk ik graag mee in het oplossen van de consequenties daarvan. Die verantwoordelijk draag ik met liefde.

[Klauwhamer]

Een maatregel afnemen -vaak tegen extra kosten- om dit soort uitglijders te ondervangen vind ik nogal wat om te verwachten van eindgebruikers. Om niet te zeggen: volstrekte kolder.

[RVervuurt]

Ik vind het woord "schade" nogal overdreven. Er is geen enkel persoon waar echt schade opgetreden is door deze bug, afgezien van misschien een bundel die eerder leeg is dan gepland. IMO moet je, als je een beperkte bundel hebt, gewoon sowieso beter opletten en meer op WiFi zitten en dan was bovenstaande bug voor jou helemaal geen probleem geweest.

[418O2]

Degene die het opmerkte moet dus een hoop extra betalen. En je merkt dus niet dat die app data aan het trekken is. Met 47mbit/s gaat het best hard met je data, dat heb je niet snel door denk ik

[watercoolertje]

Toen ik nog een beperkt bundel had was het eerste wat ik deed een limiet instellen om mijn telefoon zodat ik er niet overheen kon.

Degene die het opmerkte moet dus een hoop extra betalen.

Als ie dat echt moet betalen dan is dat een dure les.

[RVervuurt]

Een belletje naar de provider lost dat naar alle waarschijnlijkheid gewoon op, dus er is nog steeds geen schade.

[keejoz]

Ik vind het gebruik van Mbit/s een zeer slechte keuze. Wat boeit het nu hoe snel die data ging? Als het om 5kb gaat is het in een fractie van een seconde klaar. Dit zegt echt werkelijk niets over hoeveel data nu echt verbruikt werd.

[MainframeX]

Haha ok, dus de gebruikers moeten beter moeten opletten op hun databundel? Wat dacht je van userspace niet slopen en gewoon je programmatuur testen voordat je het publiceert? Fouten maken is menselijk maar we moeten niet de gebruiker de les gaan lezen op moment dat we als techneuten zelf fouten maken.

[Reactie gewijzigd door MainframeX op 8 augustus 2025 12:36]

[n9iels]

De provider is hier de schuldige, die laat de kosten oplopen tot een absurd hoog bedrag. Dit had ook kunnen gebeuren door YouTube kijken terwijl je provider een storing had, of met Chrome naar websites gaan die foto's van 5MB per stuk in laden.

De beste stuurlui staan hier weer aan wal zo te lezen. Ontwikkel zelf eens een app en kom erachter dat er wel meer dingen zijn waar je op moet letten dan grote afbeeldingen. Ik zeg zeker niet dat dit niet een issue is, maar als app ontwikkelaar kan ik begrijpen dit niet een bug is die er direct uit springt. Daarnaast vind ik een oplostijd van een paar dagen heel erg netjes, veel sneller kan eigenlijk bijna niet met een app i.v.m. de tijd die het duurt voordat een update in de stores staat

[Reactie gewijzigd door n9iels op 8 augustus 2025 10:32]

[R_Zwart]

Hoe voorkom jij dit soort bugs in 100% van de situaties?

[Prince]

Vergoeden zal er niet in zitten, maar dit is op zoveel verschillende niveau's beginnen fout te lopen dat mensen terecht alle vertrouwen in de maker zullen verliezen.

- Images niet geoptimaliseerd
- Images worden niet gecached in de app zelf
- Niet opgevallen tijdens development
- Niet opgevallen tijdens de tests
* Kijken ze niet naar dataverbruik/bandbreedte van de client?
* Doen ze geen stresstests voor hun server?
* Doen ze geen vergelijking van de statistieken tussen 2 versies in? (bvb app verbruikt x % meer CPU, zal van mobiele devices dus sneller de batterij drainen - of android zal nu performace cores gebruiken ipv efficiency cores?)

- De ongeoptimaliseerde afbeeldingen stonden op de server, dus dat had niets met nieuwe client-software te maken
- De brakke (lees punten hierboven) app is client related. Het niet cachen voelt haast alsof deze een debugging/development release was. Pas op; dit kan een menselijke fout zijn om dit zo te laten staan en kan iets verklaren.
Maar bottom line zijn er een hele hoop steken gevallen. Dit zou je kunnen verwachten van een 16-jarige jongen (edit: of dame) die op z'n eentje iets ineen knutselt; niet van een bureau dat apps en backend services maakt.

[Reactie gewijzigd door Prince op 8 augustus 2025 15:58]

[Haruhi]

Goed bezig.

Is het niet een idee voor Tweakers om vaker dit soort artikelen te maken, lampen schijnen op tech issues?

[TijsZonderH]

Wat bedoel je daar precies mee? Wat voor soort artikelen?

[Sluuut]

Ik vermoed meer inhoudelijke, technische issues die niet zo snel op andere nieuwssites voorbij komen. Wat meer de diepte in gaat, ook qua techniek.

Het is natuurlijk wel tof dat je als t.net-community zoiets constateert, het als nieuws meldt en dat je ziet dat de ontwikkelaars het relatief snel oplossen en dat ook weer als nieuws opvolgt.

Persoonlijk voelde ik sinds 10+ jaar eindelijk weer een beetje het nostalgische t.net-gevoel bij het lezen van dit artikel.

[Reactie gewijzigd door Sluuut op 8 augustus 2025 09:42]

[Haruhi]

Precies mijn gedachten. Bedankt!

[Klauwhamer]

Wat bedoel je daar precies mee? Wat voor soort artikelen?

Oneerbiedig gezegd: meer news for nerds, stuff that matters. Minder Nu.nl-vibe. Overigens begrijp ik wel dat er ook clicks moeten komen dankzij DPG, maar goed. Ik heb die wens ook wel.