Apple HomeKit-bug kan iOS-apparaten onbruikbaar maken

Een securityonderzoeker heeft details gepubliceerd over een Apple HomeKit-bug, die een denial-of-service kan veroorzaken in verbonden iOS-apparaten en aanhoudt na reboots. De onderzoeker heeft de bug naar eigen zeggen in augustus gemeld bij Apple.

Securityonderzoeker Trevor Spiniolas, die de bug ontdekte, noemt de kwetsbaarheid Doorlock en publiceert een proof-of-concept op GitHub. De bug zit in Apples HomeKit-api voor smarthomeapparaten. De bug doet zich voor wanneer aanvallers een HomeKit-apparaat instellen met een lange naam, van ongeveer 500.000 tekens. IOS-apparaten die vervolgens verbinding maken met dat apparaat, reageren niet meer, ook niet nadat deze opnieuw worden opgestart. Wanneer gebruikers een iOS-apparaat herstellen naar de fabrieksinstellingen, maar vervolgens inloggen op het iCloud-account dat gekoppeld is aan het HomeKit-apparaat, wordt de bug opnieuw getriggerd.

Spiniolas meldt dat elke iOS-app met toegang tot Apple Home-gegevens de naam van HomeKit-apparaten kan aanpassen. Dergelijke apps kunnen de kwetsbaarheid dus uitbuiten. Apple heeft in iOS 15.1 en volgens de onderzoeker mogelijk al in 15.0 een limiet geïntroduceerd op de lengte van HomeKit-namen, dus op recent geüpdatete iOS-apparaten is dit niet langer mogelijk. HomeKit-apparaten die al een gewijzigde naam hebben, kunnen echter nog steeds iOS-devices met de meest recente iOS-versies doen 'bevriezen'.

De onderzoeker benadrukt daarbij dat het aannemelijker is dat de kwetsbaarheid zal worden uitgebuit door een Home-netwerk te creëren en mensen daarvoor uit te nodigen via phishingmails. Spiniolas geeft aan dat gebruikers zich kunnen weren tegen de bug door uitnodigingen voor onbekende Home-netwerken te negeren. IOS-gebruikers die zelf HomeKit-apparaten gebruiken, kunnen zichzelf deels beschermen door 'Show Home Controls' uit te schakelen in Control Center.

Spiniolas heeft de bug naar eigen zeggen op 10 augustus gemeld bij Apple. Apple gaf volgens de onderzoeker aan dat het 'voor 2022' met een oplossing zou komen, maar stelde dit vorige maand bij tot 'begin 2022', waarna Spiniolas aan Apple vertelde dat hij de bug begin 2022 publiek maakt. De bug is nog niet opgelost door Apple. De onderzoeker is eerder aangeschreven bij een bug in macOS, die in 2019 werd gepatcht.

Spiniolas is van mening dat Apple te traag reageerde op zijn aanvankelijke melding. De onderzoeker deelt e-mails met The Verge, waarin een Apple-medewerker de bug erkende en Spiniolas verzocht om tot begin 2022 geen details over Doorlock te publiceren. Apple heeft nog niet publiekelijk gereageerd op de publicatie.

Apple krijgt al langer kritiek vanwege zijn bugbountyprogramma. Van de grote techbedrijven is Apples responsibledisclosurebeleid het jongst. Hoewel Apple relatief hoge beloningen uitdeelt, klagen ethische hackers al jaren over trage oplossingen en meldingen die in zwarte gaten lijken te verdwijnen. Tweakers schreef vorig jaar al een artikel over die problemen.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Daan van Monsjou

Redacteur

04-01-2022 • 10:42

55 Linkedin

Reacties (55)

Wijzig sortering
"Spiniolas geeft aan dat gebruikers zich kunnen weren tegen de bug door uitnodigingen voor onbekende Home-netwerken te negeren."

Dit is sowieso altijd verstandig om te doen, niet alleen vanwege deze bug.

Daarnaast wel een interessante DOS-aanval, maar erg onwaarschijnlijk om in de praktijk tegen te komen en erg waarschijnlijk dat dit in een volgende update is gefixt.

Leuk gevonden, maar in werkelijkheid dus niet echt iets om je zorgen over te maken.
Zou je inderdaad denken. Maar als je dus uitnodigingen voor onbekende Home-netwerken niet negeert, ben je alsnog de sjaak.

[Reactie gewijzigd door josh-hill op 4 januari 2022 11:00]

Je bent meestal de sjaak als je onbekende zomaar accepteert/ niet negeert, dat limiteert zich niet tot uitnodiging van home netwerken. Tevens ben ik nog nooit uitgenodigd voor een home netwerk zomaar.
Maar dan moet er dus iemand een netwerk opzetten dat publiekelijk benaderbaar is, daar een device met 500.000 tekens aan hangen en dan nog de phishingmail uit gaan sturen en hopen dat mensen gaan klikken , een iPhone hebben en de juiste iOS versie hebben draaien.

En dan? Dan heeft ie wat iPhones gebrickt waarvan hij het zelf niet eens weet.

Als je de mogelijkheid hebt om te phishen dan zijn er genoeg scams waar wel geld mee te verdienen valt. Dan ga je je phishinglijsten en scam-adressen echt niet gebruiken voor zo'n geintje.
Op zich is het toch wel best een serieuze bug. Jij en ik zullen er geen last van hebben maar de bug is zo gemakkelijk te creëren dat er vast al wel wat jonge grappenmakers bezig zijn de telefoons van hun vrienden te bricken.
Het probleem is met IOS 15.0 of 15.1 deels opgelost (we zitten nu op 15.2). Maar door iemand binnen te laten via phishing ben je alsnog gevoelig.

Tsja, men is ook gevoelig voor Whatsapp-fraude. Maar toch moet je daar wel een bepaald slag persoon voor zijn.
Als je je geen zorgen hoeft te maken, waarom wilde Apple dan dat de vinder dit probleem geheim zou houden? Dat vragen ze toch niet als er niks aan de hand is, lijkt mij.

[Reactie gewijzigd door TheVivaldi op 4 januari 2022 12:36]

Misschien omdat het gerucht dat er iets aan de hand is meer invloed heeft dan de nuance?
Omdat dit standaard policy is? Onafhankelijk van hoe ernstig de bug is.
Apple maakte zich er kennelijk wel zorgen over, want ze verzochten de vinder het geheim te houden. Als het puur een theoretisch issue zou zijn, zonder daarwerkelijk negatief nut, had Apple het toch niet geheim willen houden?

Een stuk software laten crashen biedt soms toegang tot informatie die normaal gesproken afgeschermd is.
Daarnaast wel een interessante DOS-aanval, maar erg onwaarschijnlijk om in de praktijk tegen te komen
Volgens die redenering kun je elke security-bug wel afdoen als 'niks om je zorgen over te maken'. De kans dat een specifieke bug jou treft is namelijk vaak niet zo groot. De kans dat je door een bug getroffen wordt is al een stukje groter.

Deze bug brickt je apparaat nagenoeg, direct als je met het verkeerde netwerk verbindt. Makkelijk te veroorzaken bij onoplettende gebruikers, heftige gevolgen. Netto dus een best heftige bug.

Verder vraag ik me af waarom je denkt dat dit onwaarschijnlijk is om tegen te komen. Toen een bug een paar jaar geleden ervoor zorgde dat een SMSje iphones kon laten rebooten heb ik toch veel klachten gehoord van iphone-gebruikers dat lolbroeken dat ook veel gingen misbruiken, dus schijnbaar zijn er genoeg die lol hebben met dit soort bugs.

[Reactie gewijzigd door bwerg op 4 januari 2022 12:29]

Beetje slordig om hier geen maximum op te zetten, maar ik vind het frappant wat voor impact een aanval op zo'n gimmick heeft. Een enkele applicatie zou niet zomaar genoeg systeemresources moeten kunnen vreten om de hele UI onbruikbaar te maken, alleen trager. Ik snap dat dit systeem met het OS geïntegreerd is, maar zelfs op OS-services wil je toch wel enige limieten om dit soort dingen te voorkomen.

Wat ik nog veel slordiger vind, is hoe lang dit al wel niet duurt. Apple weet hier onderhand vier maanden vanaf en het enige wat ze moeten doen om dit te mitigeren is een maximumlengte op een veld instellen. Ze hebben dit aan de frontend gefixt, maar in de backend zit de fout nog steeds. Als dit end-to-end versleutelde is, moet er in het systeem dat de data laadt nog steeds een fix komen die de naam inkort. Er is geen enkele geldige use case voor een apparaatnaam lang genoeg om de bug te triggeren. Ik ben benieuwd hoeveel van deze exploits er zullen volgen nu dat men weet dat Apple hun limieten niet goed checkt.

Dit is een onwaarschijnlijke aanvalsmethode voor hackers, maar als je er niet zoveel om geeft, vraag dan degene die de boel rapporteert niet om het nog even langer stil te houden.
Naar mijn ervaring worden reports niet serieus genomen. Zelf een aantal jaar geleden een bug in de openGL driver gerapporteerd - via google kon je zien dat dit ook een crash veroorzaakte bij een paar grote AAA games. Dus een van onze developer support-tickets gebruikt om dit te rapporteren. Eerste reactie was "working as expected".
Daarop geantwoord door hun eigen documentatie te quoten, het was heel duidelijk dat het niet reageerde zoals gedocumenteerd (dus op z'n minst is de documentatie verkeerd), en ook meteen een repro-case (standalone klein project) meegestuurd.
Reactie daarop was dat een third party library gebruikt werd en het daaraan lag. Code omgeschreven zodat precies hetzelfde gebeurt, zonder 3rd party lib.
Tot zover was het 3-4 maanden van heen-en-weer emails - altijd met enkele weken ertussen. Apple had alle informatie om dit te onderzoeken, repro-case, verwijzingen naar documentatie - een ideale case voor een developer om het op te pakken.
Op dit punt werd erkend dat het inderdaad een bug was met het verzoek het "Apple Radar" te rapporteren. Op dit punkt ben ik afgehaakt, er is genoeg tijd verspild om iemand anders te overtuigen zijn produkt te verbeteren - ik heb wel wat beters te doen.

[Reactie gewijzigd door rboerdijk op 4 januari 2022 13:42]

Niet om het goed te praten. Maar ik heb wel eens aan de andere kant gezeten met mijn werk en bug reports behandelen kost erg veel tijd van dure ontwikkelaars. Ondertussen zijn er allemaal nieuwe ontwikkelingen op de code base en plannen die de buitenwereld nog niet mag weten, waardoor de bug zo maar eens kan verdwijnen. We kregen dan ook de opdracht om ons enkel te focussen op de reports met veel votes en bij alle anderen bugs moesten we proberen de analyse tijd aan onze kant zo laag mogelijk te houden. Dit doe je vooral door heldere reproductie scenario’s te eisen van de reporters. Uiteraard vervelend voor de mensen die het melden maar het is gewoon een kosten baten verhaal helaas
Ja, snap ik - en uiteindelijk is het niet mijn product dat crashed...

Let wel, je had recht op 2-3 support requests als deel van het betaalde(!) developer abonnement, dan moet je niet zeuren dat "het duur is en tijd kost om het te onderzoeken".
Ik krijg ook wel eens vage, niet reproduceerbare bugreports, maar soms zitten er ook extreem goede tussen (reproduceerbaar, duidelijke beschrijving). Als iemand zich dan de moeite neemt om echt goede reports te maken mag je naar mijn mening best wat serieuzer nemen.

Maargoed, ze mogen doen wat ze willen, ik heb er mijn eigen mening over. Ik zou in ieder geval geen moeite meer doen nog bugs te reporten (het is ook mijn dure tijd die verspild wordt).
Ik vermoed dat dit nog niet zo makkelijk te fixen is als jij schrijft. De frontend aanpassen is deel 1, maar daarmee los je niet de gevallen op die op dit moment al bestaan in de backend. Je kunt die apparaten ook niet zomaar verwijderen, want dan zijn gebruikers ineens apparaten kwijt waar ze op vertrouwen.

Ik zou er niet blij van worden als Apple zomaar mijn deurslot verwijdert uit mijn Homekit, want dan kom ik (met een beetje pech) mijn huis niet meer in. Dus er zal echt een strategie moeten worden uitgedacht om deze devices op een nette manier uit te faseren zonder dat gebruikers daar last van hebben. Vier maanden is misschien wat lang, daar heb je een punt.

Maar de kans op een exploit is ook weer niet zo groot, want er valt niks te winnen voor het geboefte. Bij een succesvolle exploit maak je iemands toestel onbruikbaar, je beschikt niet ineens over z'n geld of wachtwoorden. Zelfs z'n sloten openen via deze hack lijkt niet mogelijk.
Het apparaat hoeft niet te verdwijnen, de parser moet gewoon de naam afkorten tot 64KiB ofzo. Ik vind zelf 1KiB al heel veel voor een apparaatnaam, ik zou na 256 karakters toch wel zeggen dat het genoeg is, met 2000 bytes heb je als het goed is ook wel de nodige extra unicoderuimte daarvoor meegenomen.

Het lijkt me verre van normaal dat gebruikers hun apparaat "Het slimme slot van de deur tegenover de kelderkast in de overloop boven, die met dat piepende schanier" noemen (en dat is nog maar 105 tekens als je de \0 op het einde meetelt). Voeg op het einde een … toe en hernoem het apparaat daarna desnoods met een API call, kan allemaal client side.

Mocht e data op tig verschillende plekken geparsed worden dan wordt het natuurlijk een complexere zaak, maar in dat geval mag er sowieso een keer een goede refactor overheen, vind ik.
LOL, hoe kom je ook op het idee om een naam van een half miljoen tekens in te gaan proberen te voeren... ik moest het ff opzoeken, maar dat is ongeveer 1000 pagina's tekst.

Dat een naam-veld niet sowieso standaard een maximum lengte heeft, in welke situatie is een naam van meer dan laten we zeggen 100 tekens nu nuttig/noodzakelijk?
Hoe kom je op het idee? Nou, edge cases bedenken voor input dat is iets wat Q&A van grote bedrijven zou moeten doen met software, en iets dat securityonderzoekers dikwijls doen om dit soort dingen te vinden als Q&A hun werk niet goed heeft gedaan.

Ik vind het bijzonder dat er geen limiet op de naam is gezet, doorgaans zet je er op zijn minst een arbitrair hoog getal (65k ofzo) op als limiet als je de data heel groot wil laten worden.

[Reactie gewijzigd door GertMenkel op 4 januari 2022 18:20]

In iOS15 zit al wel een maximale lengte aan de naam.

Maar als de actie uitgezet wordt vanaf een oudere iOS-versie, dan blijven ook de iOS15-devices als ontvanger wel kwetsbaar.
Dat las ik ook in het artikel, maar homekit bestaat al sinds iOS 8, dus ruim 7 jaar en evenzoveel versies heeft dit probleem (kunnen blijven) bestaan
LOL, hoe kom je ook op het idee om een naam van een half miljoen tekens in te gaan proberen te voeren... ik moest het ff opzoeken, maar dat is ongeveer 1000 pagina's tekst.
Omdat een zeer vaak gebruikte aanval is. Blamage dat het nog kan na decennia van dat soort aanvallen.
De onderzoeker benadrukt daarbij dat het aannemelijker is de kwetsbaarheid zal worden uitgebuit door een Home-netwerk te creëren en mensen daarvoor uit te nodigen via phishingmails.
Van alle phishing-mails die de ronde doen, waarom zou iemand in godsnaam een uitnodiging accepteren voor een onbekend iemand zijn of haar smarthome?! Of overschat ik nu echt de gemiddelde gebruiker?
Is het met phishing emails niet de bedoeling gegevens of geld te stelen? Ik zie zo 1-2-3 het nut van deze bug voor phishers niet.
phising is enkel een methode/techniek, die kun je toepassen voor wat je maar wil - in dit geval toegang(sgegevens) voor Home?
Nee, zelfs dat niet. Het enige wat er mee 'bereikt' wordt, is dat de iOS-apparaten (dus iPhone / iPad) van het slachtoffer vastlopen. Als die überhaupt homekit gebruiken, wat nog vrij zeldzaam is. En dan moet die persoon ook nog niet geüpdate hebben naar iOS 15. Wat de combinatie nog zeldzamer maakt, want homekit-gebruikers zijn nou net de mensen die vooruit lopen.

[Reactie gewijzigd door laptopleon op 4 januari 2022 12:50]

Nee, zelfs dat niet. Het enige wat er mee 'bereikt' wordt, is dat de iOS-apparaten (dus iPhone / iPad) van het slachtoffer vastlopen.
Dat is ook een doel.
Wie al wat langer meeloopt kent wel virussen die als enig doel hadden je HDD te formateren.
Of zichzelf te kopiëren of zo, zeker, maar @Alxndr had het over
in dit geval toegang(sgegevens) voor Home?
(bemachtigen neem ik aan) en dat zit er niet in.
Ik kan me bijvoorbeeld voorstellen dat iemand op die manier een telefoon "brickt" en vervolgens een mail stuurt dat die het ongedaan zal maken zodra die een paar bitcoins krijgt. Het enige "nadeel" voor de crimineel is in dat geval wel dat het, zoals ik het in het artikel lees, niet ongedaan gemaakt kan worden. Zodra het slachtoffer daar lucht van krijgt, zal deze natuurlijk sowieso niet meer tot betaling overgaan.
De onderzoeker geeft het voorbeeld van een aanvaller die willekeurige mensen phist en als mensen erin trappen ze om losgeld vraagt om weer toegang tot hun iPhone te krijgen (door van zijn kant de iPhone te kicken bijvoorbeeld).

De meeste mensen zullen hun iCloud moeten vervangen als ze hierin trappen want de bug en de workaround zijn obscuur en opnieuw inloggen op een iPhone maakt de nieuwe iPhone weer stuk. Ik denk dat er genoeg mensen zijn die er een tientje of meer voor over hebben om hier vanaf te zijn.

Ik weet niet of dit een nuttige aanvalsvector is, en ik heb ook nog niet van zulke afpersing gehoord, maar theoretisch kan het.
Studenten? Een werknemer die een “geintje” uithaalt op het werk.

Met name in de VS is het aantal apple-gebruikers een stuk hoger waardoor je dat risico sneller loopt.

Zullen het veel mensen zijn, niet echt,
maar wel irritant.
Dus, als ik het goed begrijp zit het probleem in het account en de combinatie met een apparaat waarbij 'Show Home Controls' in het control center aan staat.

Zou het dan een workaround zijn om op deze manier te werken:
  • Apparaat resetten naar fabrieksinstellingen
  • Activeren zonder in te loggen op iCloud
  • Show Home Controls uitschakelen
  • Inloggen op iCloud
Je kan niet inloggen op een IOS apparaat zonder je Apple-id (iCloud) op te geven tijdens de setup (toch niet als er ooit al een account op het toestel heeft gestaan).
Jawel hoor, dat kan prima. Ook als er eerder een iCloud account ingelogd is geweest. Mogelijk ben je in de war met de Activation Lock feature, die je vraagt om bij het op het device ingelogde iCloud account in te loggen na een factory reset. Dit wordt echter alleen gevraagd als voor de factory reset het device niet is uitgelogd van dat betreffende iCloud account.
Wellicht even verder kijken naar de juiste informatie
Een snellere workaround is geen onbekende Homekit-aanvraag accepteren.
Dat is geen workaround, maar voorkomen dat het probleem uberhaupt optreedt. Als je al met het probleem zit (om welke reden dan ook) dan heb je daar dus niks aan...
Dan doel je niet op een workarround maar op de oplossing van het probleem? Uit alle nieuwsberichten (andere sites waren al een paar dagen eerder) begrijp ik juist dat Apple nog geen oplossing heeft...

[Reactie gewijzigd door Dennisdn op 4 januari 2022 15:14]

Precies. Mijn methode is dus een workaround voor als je reeds getroffen bent door dit probleem, om toch je toestel te kunnen blijven gebruiken totdat Apple met een fix komt.
0Anoniem: 401186
4 januari 2022 12:24
De bug doet zich voor wanneer aanvallers een HomeKit-apparaat instellen met een lange naam, van ongeveer 500.000 tekens.
500.000 Tekens!!! WoW
Persoonlijk ben ik best wel een Apple fan, heb van zo'n beetje alle consumenten product categorieën wel een paar versies. Toch heb ik zo mijn bedenkingen.

De integratie is over het algemeen echt goed en zaken als de Apple Pencil, Watch en TV bieden echt een meerwaarde.

Daartegenover staat dus dit soort bugs, de originele HomePod die naar nu blijkt een ontwerpfout te hebben waardoor ze gewoon na 3 jaar stuk gaan en niet te repareren zijn, de schandalig slechte toetsenborden op de MacBook Pro serie tussen 2015 en 2019 en meer van dit soort zaken. Het wordt gewoon simpelweg met een geen commentaar onder het tapijt geveegd.

[Reactie gewijzigd door tonnert op 4 januari 2022 11:04]

het is mij dan ook een raadsel waarom jij nog een apple fan bent, maar ja, ieder zijn eigen ding!
Heel simpel, over de gehele lijn is de kwaliteit gewoon goed en doe je jaren met apparatuur. Maar sommige dingen zijn niet goed en dan moeten ze echt gedwongen worden om het juiste te doen.

Met name de originele HomePod is wel een dingetje, die dingen waren 400 euro bij introductie en begin vorig jaar bleek dat er een productiefout in zit. De reactie van Apple is het ding van de markt te halen, maar bezitters blijven nu met kapotte apparaten zitten en Apple heeft maar één reparatie; vervanging voor 300 euro.

Mijn persoonlijke ervaring met computers, telefoons en tablets van Apple is echter zonder meer gewoon goed. Levensduur van Macs en tablets zonder problemen zo rond de 8 jaar.
Apple is tegen right-to-repair (tot recent, want er zat wetgeving in de pijplijn) en het mogelijk maken zelf iets te doen met je spullen tenzij er expliciet toestemming voor gegeven is (Windows op Apple hardware was een no-no tot bootcamp). Ik zie Apple een beetje als de Duplo in de IT: leuk voor babys en kinderen, maar als je serieus bent stap je over naar (technisch) lego. Dat handholding en pampering is leuk voor even. En dan deze bug: klinkt als een klassieke bufferoverflow en dat ligt dan tot augustus....
Een bufferoverflow is zo nieuw dat Apple onmogelijk van deze 20 jaar oude aanval kan weten,
En dit is niet de eerste blunder waarbij Apple geen zeer basale checks doet.
Een webserver die gebruteforced kan worden omdat geen limiet op pogingen (per minuut) had gezet.

Als een bedrijf 20 jaar oude scriptkiddie 'hacks' niet weet te voorkomen moeten ze per direct de bek houden over veiligheid...
Die toetsenborden hebben een vervangingsprogramma gekregen. Ik heb 2 keer Airpods Pro gekocht en beide kregen die ook een soort storing, en hoorde ik geluid van een overstuurde speakers, ook hiervoor is kennelijk een vervangingsprogramma. Het is allemaal niet fraai maar als je zoveel sales hebt als Apple en vaak iets toch net even anders doet (= innovatie) dan gaat er ook relatief vaak iets mis.

Zelf erger ik me aan het feit dat een batterijvervanging van mijn 44mm Apple Watch Series 4 Stainless Steel van €430 kost bij Apple; ter referentie, een nieuwe van RVS kost €779 (een Aluminium model zelfs €459).
Je moet de gelinkte pagina nog even doorscrollen. Iets verderop staat het kopje 'Batterieserviceleistung' (duitse pagina...). €96,90 voor een nieuwe batterij buiten garantie. Is ook veel geld voor een klein accuutje van een apple watch maar allicht de moeite waard als de watch nog niet al te traag is.
_/-\o_

De watch is nog prima. Voor 100 euro wordt de forcerouchsensor geloof ik ook vervangen (dat is de interface tussen scherm en behuizing). Bij Apple blijft het waterdicht (hoop ik) extern ben ik daar minder zeker van.

Wat fijn dat je me hierop wijst!
IOT intergratie is want anders dan OS ondersteuning
Dat je met Windows meer keus voor hardware hebt is voor sommigen fijn. Maar ik wil gewoon een zo goed mogelijk werkende portfolio aan producten.

Als ik ergens heen wil moet mijn auto gewoon direct starten, als ik wil koken moet mijn pan zo snel mogelijk op temperatuur zijn, wil ik muziek luisteren dan ga ik niet eerst met kabels pielen, moet de verwarming aan, dan ga ik niet opstaan.

Ik heb bijvoorbeeld Tradfri van Ikea geprobeerd. Maar die reageerde niet altijd goed, of hij leek contact met de bridge of knop te verliezen, dus ik heb die zooi teruggebracht en gewoon voor het dubbele Hue gekocht. Als ik over 300 dagen het licht aan wil zetten, moet het gewoon aan gaan.

Waarom zou je overigens Apple haten? Wat doet dat bedrijf om jou dwars te zitten?
Alsof alles wat niet Apple is "niet direct start", "snel op temperatuur is", "aan de kabels gepield moet worden voor het werkt" etc etc?

Precies die houding van de Apple fans is wat ik "haat" aan het merk, afgezien van de alle leugens die ze verkopen: dat data niet terug te halen is, appararaten echt niet repareerbaar zijn - je kunt beter een nieuwe kopen en om over de koppelverkoop met onnodig dure accessoires/kabeltjes etc. nog maar te zwijgen.

Ik zeg niet dat ze geen kwaliteit leveren, maar er zijn genoeg andere merken die dat ook doen (nee, misschien niet het goedkope IKEA spul, maar dan ga je ook direct naar het andere uiterste).

Het is puur een merk/imago waar je fors extra voor betaald. Afgezien dat ze nu met de M1 chips een wel troef in handen hebben, kun je over het algemeen veel meer voor veel minder krijgen.
Dat ik 'veel meer voor veel minder kan krijgen', natuurlijk, maar ik wil graag 30% meer betalen voor 5% meer kwaliteitsbeleving. Dat kabels of accessoires onnodig duur zijn boeit me ook niet. Laat ik het anders zeggen, voor dingen die ik veel gebruik let ik niet zo op geld.

Die dingen die ik noem zijn natuurlijk een paar voorbeelden. De laatste Windwslaptop had Vista. Vers uit de dos kreeg ik een BSDO. Na heel veel ellende wilde ik downgraden naar XP, maar het blek dat de Hardware nog geen XP drivers had (en die waren helaas wel nodig). Sinds dien heb ik 4 Windowslaptops van mijn werkgevers gehad, HP Probook, Lenovo Thinkpad, Dell Latitude, HP Elitebook (huidige laptop). Dat zijn echt niet de minste apparaten. Maar toch sta ik regelmatig bij IT. Mijn huidige Elitebolk 830 G4 is constant aan het coolen, ook als ik dat ding 4 uur niet heb gebruikt, daarnaast erger ik me kapot aan een coil whine (en dit is niet de enige uit het rijtje). Waarom kunnen ze hun boards en componenten niet zo kiezen dat je daar geen last van hebt? Al die andere laptops leggen het kwa beeld (schermen zijn half zo fel) en audio (nauwelijks lage tonen) ook af tegen mijn MacBook Pro.

Daarnaast noem ik ook het voorbeeld Hue vs Tradfri (geen van beide zijn Apple). Dat is echt niet de onderkant van de markt, dat vind je bij Action. Zeker een jaar of 4 geleden was dat ook gewoon prijzig spul, zij het goedkoper dan Hue.

En die auto die wél direct start is ook geen auto van Apple. Dat is een Toyota omdat ik de kwaliteit van Peugeot, Mercedes en VW te mager vond. Al die autos hebben mij wel eens laten staan in 100.000 km. Maar Toyota niet, niet eens in 300.000 km, die laat ook duidelijk blijken als de 12V accu een keer vervangen moet worden in plaats van dat hij gewoon niet meer start. En dit wordt onderbouwd door betrouwbaarheidsonderzoeken.
Zolang de illusie heerst dat het allemaal beter en veiliger is kan Apple ook lekker achterover hangen natuurlijk!

De fixes die ze wel doen komen dan wel snel op een toestel terecht, maar dat is dus een vertekend beeld/halve verhaal...

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee