Apple: veiligheid producten is niet in geding door uitlekken iBoot-code

Apple bevestigt in een reactie dat broncode van de iBoot-bootloader online is verschenen, maar de fabrikant benadrukt dat het om oude code gaat en volgens het bedrijf is er geen invloed op de veiligheid van producten.

De veiligheid van zijn producten is volgens Apple by design niet afhankelijk van het al of niet geheimhouden van broncode. "Er zijn veel beveiligingslagen op hardware- en softwaregebied ingebouwd in onze producten, en we moedigen klanten altijd aan naar de nieuwste software te updaten om de voordelen van de laatste bescherming te hebben", meldt het bedrijf in een verklaring aan media zoals TechCrunch.

Apple spreekt daarnaast van 'oude' broncode van drie jaar geleden. Inmiddels is de code voor het bootproces van iOS 9, met een beroep op de Amerikaanse dmca-wet, van GitHub gehaald. Daar verscheen de code onlangs, na vier maanden geleden al op Reddit gestaan te hebben. Beveiligingsdeskundigen gaven aan dat de code inzicht kan geven in bugs en kwetsbaarheden van iOS, met de kanttekening dat dit afhangt van aanpassingen die Apple sindsdien heeft doorgevoerd.

Reacties (76)

Zijn er überhaupt interessante ontdekkingen gedaan in de broncode?

De hoop is dat deze bootloader zal gaan werken op ARM bordjes en dat dus iOs op non-Apple hardware zal werken.

Mag je eerst nog aan de iOS code gaan komen. Een bootloader gaat je niet ver brengen.

iOS op je Pi lol

Pi + touchscreen + iOS, en je hebt een hombrew iPod touch.
En ARM zit ook in genoeg non-Apple tablets.
Voor de spielerij is iOS op verschillende hardware werkend te krijgen is al genoeg.

Windows 10 draait al op Pi.

Apple kan roepen wat ze wil, maar dit gedoe geeft me allesbehalve vertrouwen. Er is iedere keer wat de laatste tijd.

Ik vertrouw Apple nog steeds.. ja een oude code is uitgelekt.. zo wat?

De code van Android, Linux en een hoop andere open source software is publiek beschikbaar, dus het is inderdaad niet noodzakelijk zo'n probleem dat de (oude) code van Apple uitgelekt is. Security through obscurity is geen veiligheid, dus behalve dat het jammer is voor Apple, heeft het met veiligheid weinig te maken.

De bootloader van android toestellen is meestal ook niet open source, Samsung geeft echt zijn bootloader code niet vrij. De reference code van android voor een bootloader is verwijderd door google in 2012 (https://android.googlesou...otable/bootloader/legacy/), reken maar dat die van Samsung ondertussen behoorlijk afwijkt.

Daarnaast heeft apple sinds deze zomer wel de broncode van de arm versie van de kernel vrijgegeven:

https://github.com/apple/darwin-xnu/tree/master/osfmk/arm64

Op dit moment is de situatie Google / Apple exact gelijk: bootloaders closed source, kernels open source. Behalve dat de source van iboot dan gelekt is ;-)

Security through obscurity is geen veiligheid,

Security through obscurity is een mechanisme die je in ieder geval niet als hoofdzakelijk middel moet inzetten omdat het je inhoudelijk inderdaad nergens tegen beschermd maar hoe je kan roepen dat het geen veiligheid brengt is me een raadsel.
Als men niet weet hoe je systeem werkt is het objectief moeilijker om er binnen te dringen. Het brengt dus wel veiligheid, het is alleen relatief marginaal ten opzichte van de contextueel juiste manier van beveiligen en mag slechts als een laagje worden gezien.
Security through obscurity is zeker wel een ding. Hoe denk je dat overheden en in specifiek diensten als de AIVD werken? Hun werk hangt gewoon glashard af van de onbekendheid van wat ze exact uitvoeren. Van obscurity dus.
Een andere linux username aanmaken zodat een aanvaller zowel de username als password moet kraken in plaats van alleen het password heeft ook een hoge obscurity factor.
Geen geheim maar toch stiekem wel.

Een broncode waar alleen mensen met een Apple bril naar hebben gekeken die plots en ongecontroleerd publiekelijk is gemaakt is zeker wel een risico. Een risico die ze bij Apple adequaat lijken te hebben beheerst gezien de tijd die er tussen de leak en dit statement zit.

[Reactie gewijzigd door Koffiebarbaar op 9 februari 2018 10:36]

Mijn bewering was inderdaad wat kort door de bocht...

Het komt er volgens mij vooral op neer dat open source software het voordeel heeft dat er - tenminste als het populair genoeg is - vrij veel mensen op zoek gaan naar fouten in het systeem en deze dan ook braaf melden. Er zullen ook altijd mensen zijn die fouten zoeken om deze te misbruiken, maar over het algemeen wordt het als een voordeel gezien dat er meer kritisch naar gekeken kan worden.

Security through obscurity kan werken, maar dan moet je obscurity wel goed zitten, wat bij software per definitie niet echt het geval is, want iemand met voldoende kennis kan altijd via reverse engineering analyseren wat er in de code gebeurt omdat de gecompileerde code beschikbaar is, want anders zou je het programma niet kunnen uitvoeren. Je hebt dan wel zoals je zegt een extra laagje dat het moeilijker maakt, maar net de groep mensen met de meeste kennis en dus ook het grootste risico houd je er niet (lang) mee tegen.

Bij het AIVD is dat anders, omdat enkel medewerkers van de AIVD een goed inzicht hebben over wat er precies gebeurt en je het meeste ook niet zomaar kan afleiden door te observeren wat ze doen. Tenminste, als je medewerkers goed gescreend en dus betrouwbaar zijn

Security through obscurity is - wanneer je het vergelijkt met een populair open source project - dus op zich geen echte beveiliging, maar een extra drempel die genomen moet worden. Wanneer je echter een klein open source project hebt, is de kans dat er anderen kritisch naar de code kijken vrij klein, wat zowel positief als negatief kan zijn, maar eerder negatief omdat je dat dus niet weet.

"Als men niet weet hoe je systeem werkt is het objectief moeilijker om er binnen te dringen."

In de context van software, waar we het nu over hebben is het natuurlijk wel zo dat Security through obscurity niet goed werkt.

Het voorbeeld van de AIVD is anders, je kunt software in huis halen (of de toegang tot) om het te hacken en te bekijken, iets wat je met de AIVD niet kan doen.

Uiteindelijk komt het er op neer dat software beveilig wiskundig moet kloppen, anders werkt het niet. Dat wiskundige gedeelte is nogal moeilijk omdat je ook wiskundig aan kunt tonen dat software niet goed is beveiligd en dat ook zo kan onderbouwen.

In de context van software, waar we het nu over hebben is het natuurlijk wel zo dat Security through obscurity niet goed werkt.

Volgens mij is dat min of meer in dezelfde lijn met wat ik zeg een regel boven de regel die je quote?

Uiteindelijk komt het er op neer dat software beveilig wiskundig moet kloppen, anders werkt het niet. Dat wiskundige gedeelte is nogal moeilijk omdat je ook wiskundig aan kunt tonen dat software niet goed is beveiligd en dat ook zo kan onderbouwen.

Dit spreek ik nergens tegen. Maar naast je kloppende "echte" security is er niets mis met obscurity.
Je kan ook alles in orde hebben, lekker alles arrogant uit de doeken doen en iedereen vertellen hoe je netwerk/systeem werkt omdat je toch alles op orde hebt maar de eerste de beste keer dat je dat onverhoopt toch niet niet hebt (je blijft een mens), of ergens een lek stukje software hebt, ben je gewoon de sigaar natuurlijk. En dan heb je met je goede gedrag evengoed een issue.
Obscurity vind ik al met al als additionele laag prima thuis horen in een kloppend totaal security beleid. Het is populair hier om Tweakers om er op de reageren alsof het de plaag is maar dat is m.i. gewoon onterecht.

[Reactie gewijzigd door Koffiebarbaar op 12 februari 2018 14:11]

Het grote verschil ik hier wel dat open source software vanaf een vroeg stadium publiek beschikbaar is. Hierdoor is de code al grotendeels gescreend door de community voordat deze op grote schaal actief gebruikt wordt. Daarnaast komt deze open source software met uitgebreide platformen waar op- en aanmerkingen op de code kunnen worden geplaatst, gedeeld en besproken.

Als besloten software, geschreven door een vast team, onverwachts naar buiten komt is de kans groot dat andere ontwikkelaars kwetsbaarheden zullen vinden die te wijten zijn aan programmeerstijl. Ook kan het zijn dat er bewust kwetsbaarheden in de code zitten om de performance te verbeteren (of bugfixes) die te specifiek zijn om te raden. Nu kunnen deze in de code teruggevonden worden.

Je kan dus zeggen dat het uitlekken van de broncode een zegen is. Onveilige items worden eerder ontdekt en daarna snel verholpen (geen enkel bedrijf wil aan de schandpaal).

Niet echt. Smommige toestellen krijgen geen updates meer. Sommige eigenaren van meer recente toestelen willen geen updates omdat ze vrezen dat ze dan een update krijgen die hun toestel trager maakt.

Uiteraard kun je zeggen dat op Android verre van iedereen de laatste updates heeft. Dat is juist maar het grote verschil is dat de oude Android versies zeer goed nageplozen zijn. De Apple code krijgt nu de allereerste bug-check ooit.

OpenSource is echt niet gerelateerd aan hoeveel bugs er in een code zit.

Ik denk dat het feit dat Android7.0 totaal geen EC crypto ondersteund hier wel een goed voorbeeld van is. Opensource is leuk, maar niemand loopt alles 24/7 te checken, en ook al zijn er meerdere ogen apple heeft die ook. De hoeveelheid kennis die vaak nodig is om kritieke punten te begrijpen is niet zo widespread beschikbaar. OpenSSL was opensource, veel gebruikt, en toch zaten er heel erg veel issues in. Opensource zegt helemaal niks over code quality, of de hoeveelheid bugs.

Veel oauth implementaties zijn ook opensource, en vaak zo lek als een mandje. Het hele idee van een "client_secret" is zo dom als maar kan, eigenlijk een visite kaartje om gepowned te worden.

[Reactie gewijzigd door jabwd op 9 februari 2018 10:30]

Offtopic:

Sommige eigenaren van meer recente toestelen willen geen updates omdat ze vrezen dat ze dan een update krijgen die hun toestel trager maakt.

Dit soort mensen mogen van mij ook niet klagen als hun accounts gehackt worden.
Die geven dan gelijk bedrijven als Apple de schuld (Oh, en Rusland niet te vergeten) terwijl ze zelf gewoon slordig met hun security en data omgaan.

De kans is groter dat een bug gemeld wordt bij Apple.
1) Roem / media aandacht
2) Bug bounties

En als je al kwaadwillend bent en een bug gevonden hebt, dan is de kans sterk aanwezig dat diezelfde bug ook gevonden wordt door iemand die wel goede bedoelingen heeft, en de bug dus alsnog opgelost wordt waardoor kwaadwillende het niet meer kunnen misbruiken.

Fijn dat de oude Android versies heel goed nageplozen zijn, maar als er kwetsbaarheden in zitten en jouw toestel krijgt geen patches / updates om die te verhelpen dan lijkt me dat eerder een nadeel dan een voordeel.

Als iedereen erin kan spitten doet niemand het, tenzij er geld verdiend kan worden. Linux had ook vier jaar lang de CVE-2016-072 bug in haar kernel code zonder dat het bekend was (wie weet wisten de NSA het wel)-volgens jouw epistel,zou dit niet kunnen gebeuren want die fout zou allang gevonden moeten zijn

Ho ho, hij zegt dat de kans groter is dat het wordt gevonden. Het blijft een kans werkje.

En natuurlijk zijn er ook onder open source goeie en slechte producten. Het verschil zit er in dat jij als gebruiker de moeite zou kunnen nemen om de code te inspecteren.

Of je dat wel of niet doet is een heel ander verhaal

Ho ho, hij zegt dat de kans groter is dat het wordt gevonden.

Ook dat lijkt mij onzin. Het is niet zo dat de code van Apple niet door honderden/duizenden ontwikkelaars ingezien wordt. Toevallig staan zij veelal op de loonlijst van Apple, maar dat is geen verschil. Persoonlijk denk ik dat het vooral erg geromantiseerd wordt over de code screening van Open Source software. Er wordt net even te vaak gedaan of closed source software code nadat het geschreven is in een kluis beland en nooit meer naar gekeken wordt. Dat is natuurlijk onzin.

Dit is natuurlijk wel afhankelijk van de vraag of iemand met de juiste kennis onbetaald uitgebreid naar het stuk software dat jij gebruikt gaat kijken.

Dat zal in sommige gevallen vast gebeuren maar in heel veel gevallen ook niet. Lang niet iedereen kan zelf code screenen ook als is het open source.

Het grote verschil ik hier wel dat open source software vanaf een vroeg stadium publiek beschikbaar is. Hierdoor is de code al grotendeels gescreend door de community voordat deze op grote schaal actief gebruikt wordt. Daarnaast komt deze open source software met uitgebreide platformen waar op- en aanmerkingen op de code kunnen worden geplaatst, gedeeld en besproken.

Als besloten software, geschreven door een vast team, onverwachts naar buiten komt is de kans groot dat andere ontwikkelaars kwetsbaarheden zullen vinden die te wijten zijn aan programmeerstijl. Ook kan het zijn dat er bewust kwetsbaarheden in de code zitten om de performance te verbeteren (of bugfixes) die te specifiek zijn om te raden. Nu kunnen deze in de code teruggevonden worden.

Dit is pure speculatie, in de praktijk is het heel vaak gebleken dat ook publiek beschikbare code helemaal niet zo nauw onder de loep is gelegd en dat daar ook nog jaren- of in sommige gevallen decennia-oude bugs in zitten. Ook is gesloten code niet allemaal het prutswerk dat je doet suggereren. Het is wel populair om te roepen dat open-source zoveel beter in elkaar zit maar dat is niet mijn ervaring als softwareontwikkelaar.

[Reactie gewijzigd door Argantonis op 9 februari 2018 03:59]

De tijd moet uitwijzen of het speculatie is.
Geen speculatie, maar een feit, is dat kans op het vinden van kwetsbaarheden vele malen groter is bij code die onder de loep ligt dan code die geheim is.

Verder vergelijk ik het een beetje met mensen die visite krijgen. Vaak krijgt het huis dan een extra schoonmaakbeurt.
Bij Android (veel visite) ligt de veiligheid puur in hoogwaardig programeeerwerk.
Bij Apple is het meer 'men ziet toch niet dat het een rommmeltje is in mijn huis' beveiliging. (security through obscurity)

Code van Apple ligt ook onder de loep van heel veel ontwikkelaars die door Apple betaald worden.

Code van heel veel open source projecten is door iedereen in te zien maar niemand kijkt ernaar.

Wat is veiliger?

Ach ja ik heb liever closed source die is geaudit door meerdere externe partijen dan open source software waar iedereen kan meekijken maar niemand dat doet

Elk bedrijf dat zijn software niet voorzichzelf schoonhoud is fout bezig. Ik ga er van uit dat Apple zijn code wel schoon houd. Dat maakt onderhoud en testen vele malen goedkoper. En ze hebben nogal wat code om ge onderhouden en testen.

Elk stukje software die ik en mijn collega’s schrijven, word nagekeken door een andere collega, en daarbij hanteren we een aantal afspraken om de code netjes te houden. Dat scheelt op den duur veel tijd en geld. Ik denk dat het bij Apple niet anders is.

inderdaad, ik vind het jammer dat er door misbruik code van een groot bedrijf naar buiten is gekomen. Maar Apple heeft al aardig wat zelf gedeeld via open source, en met elke grote overstap van iOS etc is er genoeg verandering dat ik niet denk dat morgen mijn telefoon opeens ransomware heeft ofzo. En aan de andere kant, Apple gaat ook even nadenken over iOS 12's update en hoe ze verder dat kunnen verbeteren mocht 12 bijv uitlekken.

inderdaad, ik vind het jammer dat er door misbruik code van een groot bedrijf naar buiten is gekomen.

Dat code (van een groot bedrijf) naar buiten komt (door "misbruik"?) is toch juist fijn?

Maar Apple heeft al aardig wat zelf gedeeld via open source,

Wacht, was het nu juist goed of slecht? Of alleen goed als Apple het/iets doet?

en met elke grote overstap van iOS etc is er genoeg verandering dat ik niet denk dat morgen mijn telefoon opeens ransomware heeft ofzo.

Als je elke update je bootloader (iBoot) veranderd, kun je juist problemen verwachten. De verandering die jij noemt zal overigens vooral functioneel zijn.

En aan de andere kant, Apple gaat ook even nadenken over iOS 12's update en hoe ze verder dat kunnen verbeteren mocht 12 bijv uitlekken.

Dus nu is het weer goed als Apple juist niet open source gaat?
Imho is het idee dat je alleen iOS/OSX op Apple hardware kan draaien al broken.
Maar wat gaan ze voor de gebruiker dan verbeteren?

Ik vertrouw Apple nog steeds.. ja een oude code is uitgelekt.. zo wat?

Je snapt dat je jezelf eigenlijk vreselijk tegenspreekt. Als iets uitlekt is dat altijd onvrijwillig, gezien vanuit het bedrijf. Anders zouden ze het een release noemen. Als het onvrijwillig is is het dus per definitie een security probleem. Dus is het per definitie iets waardoor je Apple niet/minder kan vertrouwen.

Het gaat niet alleen om de impact van de code die nu op straat ligt maar het feit dat het gebeurt is. Iemand heeft dit gedaan met een bewuste of onbewuste reden. Die persoon is dus een security flaw. Wat heeft deze persoon/personen nog meer aan source code waar wel misschien serieuzere problemen mee kunnen komen. En wat is de motivatie om dit vrij te geven van deze persoon?

Het feit dat Apple zijn security niet goed op orde heeft en daarom source code kan lekken is een groter probleem dan de code zelf.

Eens dat Apple de laatste tijd aan het kwakkelen is. Het aantal updates dat Apple de laatste tijd heeft uitgebracht geeft wel aan dat ze er elke keer boven opzitten. Dat geeft me juist wel vertrouwen.
Daarnaast is de wereld (volgens mij) steeds meer aan het digitaliseren. Dus er zullen ook steeds meer kwaadwilligen bijkomen. Daarom is het juist goed om te zien dat Apple een statement afgeeft en het niet aan zich voorbij laat gaan.

Het is alleen zo jammer dat Apple die updates schijnbaar zelf niet test. Meerdere mensen gesproken en na elke update zijn er weer problemen, van simpele crashes tot mensen waarbij hun telefoon in een boot loop raakt. Heel leuk dat ze er bovenop zitten maar als ze van tevoren niet afdoende testen zullen de gebruikers vanzelf een keer genoeg krijgen van Apple. Ik heb al vrienden die overstappen naar Android door het gezeik met Apple updates.

Inloggen zonder een paswoord invoeren en daar een patch voor uitbrengen geeft me alles behalve vertrouwen in het qa proces.

Met elk item komt Apple dan ook in het nieuws. Wanneer andere bedrijven 'stuntelen' wordt het nooit zo groot in het nieuws uitgelicht dan als het bij Apple gebeurt.

Uiteraard zijn er enkele gevallen die echt niet door de beugel kunnen, zoals het 'root probleem' en de fouten in iOS 11. Maar alsnog is get gras niet altijd groener bij de overburen/concurrenten.

Onjuist.
Het Apple kamp heeft oneidig vaak zitten vitten op Android veiligheid.
Frontale aanvallen en haatcampagnes en meer bedekte 'ik betaal graag wat meer voor veiligheid' steken onder water.

Met elk item komt Apple dan ook in het nieuws.

Ten eerste denk ik dat dat wel meevalt, en ten tweede rekent Apple een premium voor hun toestellen en roep je dat vergrootglas daarmee ook wel een beetje over je af als bedrijf.
Als je privacy verkoopt lijkt het me voor zich spreken dat zoiets als dit redelijk breed word uitgemeten.

[Reactie gewijzigd door Koffiebarbaar op 9 februari 2018 10:43]

Misschien geen issue voor nieuwe devices, maar er zijn ook devices die zijn blijven hangen op iOS9 en dus wel kans hebben op een aanval, daar deze devices nog steeds gebruikt worden.

Je denkt dat Apple hun code met elke iOS versie compleet herschrijft? Natuurlijk, er zal wat in veranderd zijn, maar het grootste deel zal nog gebruikt worden.

Dit kan gebruikt worden om potentiele buffer overflow exploits te vinden.

Maar aangezien het om de bootloader code gaat, is het niet zozeer een security issue (wellicht tenzij iemand de telefoon echt in handen krijgt), maar kan het ook de jailbreak community goed helpen.

En wat Apple zegt is natuurlijk waar; het openbaren van de code betekent niet dat die niet veilig meer is. Anders zou open-source software nooit veilig kunnen zijn.

[Reactie gewijzigd door GekkePrutser op 8 februari 2018 22:19]

Je denkt dat Apple hun code met elke iOS versie compleet herschrijft? Natuurlijk, er zal wat in veranderd zijn, maar het grootste deel zal nog gebruikt worden.

Ik denk juist dat bij Apple de kans het grootst is dat ze daty niet doen.
De denkwijze van Apple is zichtbaar bij het design v/d kast. Zeer minimale wijzigingen sinds de iPhone waarmee ze doorbraken.

Tjah t is maar wat je minimale wijzigingen noemt. Geen enkele fabrikant die grotere wijzigingen heeft gemaakt overigens.

Er zijn nog zat iphone 4sjes in gebruik ja, voornamelijk bij (wat) ouderen en kinderen zie ik ze nog wel. Die staan maximaal op iOS9, exploits zoeken zal makkelijker kunnen worden dmv de sourcecode lijkt mij.

Er zal trouwens vast ook een ipad zijn die niet voorbij iOS9 is gekomen.

Een iPhone 5 uit 2012 kan iOS10 draaien. Dus als je nog op 9 zit heb je een 4s uit eind 2011, dat is inmiddels ruim 6 jaar geleden. Wellicht dat het toch tijd wordt om een keer te upgraden, ik weet dat sommige mensen van mening zijn dat ze hun duurgekochte telefoon langer moeten kunnen gebruiken dan de periode tussen het onstaan en de val van het Romeinse rijk, maar ik denk dat als je ruim 6 jaar met dezelfde telefoon hebt kunnen werken, je genoeg waar voor je geld gehad hebt om een nieuw toestel te overwegen (als je echt zo zit met de potentiële beveiliginsdreiging).

Dat kan, maar alleen op ios devices t/m de iphone 4s. Iphone 5 en hoger kunnen ook op ios 10 draaien.
En de 4s is van 2011, dus ... li

Ik snap dat Apple een DMCA heeft gestuurd maar de code is toch ergens nog wel terug te vinden. Ze hadden het net zo goed er op kunnen laten staan redeneer ik.

Voor de rest hadden meerdere mensen ook aanwijzingen gevonden dat het zelfs om test code ging ivm de hoeveelheid code review comments die gevonden zijn en hoe inconsistent de code was op sommige vlakken. Uiteraard bestaat er ook een kans dat de productie code een rommeltje is, maar dat betwijfel ik ergens.

In conclusie, cool dat de code is gelekt en je kan het vast nog ergens terug vinden om te onderzoeken maar ik denk dat de waarde ervan minimaal is.

*edit* grammar.

[Reactie gewijzigd door Anoniem: 160587 op 9 februari 2018 10:19]

Door de DMCA is er in ieder geval een grote bron minder, de code zal daardoor niet direct opvallen voor mensen die er "toevallig" voorbij komen tijdens een rondje surfen.

Die mensen zijn het gevaar niet. De broncode is beschikbaar op het internet, degene die er iets mee kunnen of willen, hebben die broncode ondertussen wel of weten dat te vinden.

Door die DMCA is in elk geval bevestigd dat het om authentieke code gaat. Die ondertussen op Github zo vaak geforkt en geherforkt is dat die toch niet meer van internet af te krijgen is.

Ik snap dat Apple een DMCA heeft gestuurd maar de code is toch wel nog terug te vinden. Ze hadden het net zo goed er op kunnen laten staan redeneer ik.

Ik wil het nog sterker stellen.
Als Apple echt voor de veiligheid v/d gebruikers staat zouden ze geen DCMA en ander juridische stappen nemen.
De reden is deze.
Kwaadwillenden gaan nu per direct met de code aan de slag.
Goedwillenden kunnen dat ook maar hebben nu veel minder de motivatie om bugs te melden omdat Apple ze dat kapot procedeert ivm met het in bezit hebben van illegale code.

Ik sluit mij daar bij aan

Ik vind het toch wel zorgwekkend dat het uberhaupt gelekt is. Hoe zou dat in zn werk gegaan zijn?

Mijn theorie: Een developer die de code (ooit) naar een persoonlijke laptop/computer heeft gehaald, die vervolgens gehackt wordt/in verkeerde handen raakt.

Vooral dat het 'maar' iOS 9 is (meer dan 2 jaar oud), suggereert dat het geen up-to-date systeem is waar het uit is gelekt.

iOS 9 is wel het meest up-to-date voor miljoenen gebruikers.

Dat was niet zijn punt, de code is niet meer up-to-date en dat is voor actieve developers vaak wel het geval, dus suggereert het dat de developer of niet meer in dienst is bij Apple, of ergens een back-up had gemaakt van deze code, of weet ik het hoeveel van deze scenario's er zijn.

Betreft de laatste versie voor miljoenen gebruikers: Zo'n zeven procent van de iOS devices welke nog een actieve internet verbinding hebben, draaien op iOS-versie 9 of eerder. Dat zijn er inderdaad behoorlijk wat, maar het is niet dat het toestel in eens onveilig is geworden zonder bijvoorbeeld fysiek toegang.

spectre en meltdown he

Ik weet niet hoe dat bij Apple gaat maar bij eigenlijk alle bedrijven waar ik gewerkt heb zou elke ontwikkelaar de complete sourcecode zo op een USB stick of telefoon kunnen zetten en er mee naar buiten lopen.

Een ander belangrijk ding is dat hiermee iOS-emulators (op andere ARM devices), een stap dichterbij komen, hoewel er natuurlijk nog een lange weg te gaan Is.

De inhoud van de DMCA takedown kun je hier vinden:
https://github.com/github.../2018/2018-02-08-Apple.md

Ben ik de enige die gewoon nieuwsgierig is naar de broncode en er wilt kijken of die er nog wat van opsteekt laat staan tot in hoeverre die t kan volgen? Ben er wel benieuwd naar. Hobby matig. Nerd gehalte enzo

De veiligheid is sowieso niet voor de consument, maar voor Apple. Die proberen nml met man en macht hun producten zo gesloten mogelijk te houden, en zoveel mogelijk controle erover te bewaren. Als je daaruit kunt losbreken, is de "veiligheid" gebroken... voor Apple. Voor de gebruiker is er dan ineens vrijheid.

De veiligheid is sowieso niet voor de consument, maar voor Apple. Die proberen nml met man en macht hun producten zo gesloten mogelijk te houden, en zoveel mogelijk controle erover te bewaren. Als je daaruit kunt losbreken, is de "veiligheid" gebroken... voor Apple. Voor de gebruiker is er dan ineens vrijheid.

De gebruiker had al de vrijheid om niet voor het "gesloten" systeem van Apple te kiezen. Als je een iPhone aanschaft en daarna gaat klagen dat je alleen apps uit de app store kunt installeren, ben je gewoon aan het zeuren want dat wist je van tevoren. Apple koop je niet voor de vrijheid maar voor het gemak.

Dat is niet helemaal waar. Er zijn zat mensen die een iPhone kopen omdat het een iPhone is. Die mensen vinden dat ze geen keus hebben. Er zijn ook mensen die een iPhone kopen omdat ze simpel niets anders kennen (vrienden, collega's, hebben dus allemaal ook een iPhone). Weten zij veel wat ze allemaal op hun hals halen.

De kreet "dat weet je van tevoren" gaat bij veel producten niet op, ook al zou je dat wel kunnen stellen. Ik vind dat eigenlijk een beetje gemakkelijk, om zo de beperkingen (die de een niets vindt, en de ander geweldig vindt) maar als het ware af te wimpelen.

Wat een flutantwoord van Apple, er zijn nog genoeg mensen die op iOS 9 draaien (de iPhone 4s). Die dus niet "kunnen" upgraden naar een nieuwere versie.

Als je ze echt wil helpen, dan upgrade je de 4s alsnog, is het complete probleem de wereld uit

Jammer dat ze zo aan het prutsen zijn daar de laatste tijd, geeft mij weinig vertrouwen als iPhone bezitter.

Edit: reactie aangepast nav correctie.

[Reactie gewijzigd door Segafreak83 op 9 februari 2018 08:26]

Iphone 5 kan nog op ios 10, dus gaat om de 4s of ouder. 4s is gereleased in 2011..., wordt misschien tijd voor een upgrade.