Apple zegt met opzet kernelcache in iOS 10 niet te hebben versleuteld

Apple claimt met opzet de kernelcache in iOS 10 niet versleuteld te hebben. Tot nu toe paste het bedrijf encryptie toe op dat gedeelte van zijn mobiele besturingssysteem, maar volgens Apple is dat niet nodig, omdat de kernelcache geen gebruikersgegevens bevat.

Daardoor komt de privacy van gebruikers niet in gevaar, claimt Apple in een statement tegen TechCrunch. Apple heeft zich in de afgelopen jaren sterk gericht op encryptie om de privacy van gebruikers te bevorderen. Daarom versleutelt het mobiele besturingssysteem gebruikersgegevens.

Het niet-versleutelen van de kernelcache in iOS 10 geeft Apple naar eigen zeggen de mogelijkheid om de prestaties van het mobiele besturingssysteem te optimaliseren. Bovendien kunnen beveiligingsonderzoekers nu makkelijker rondsnuffelen in de code, en eventuele kwetsbaarheden opsporen en doorgeven aan Apple. Daar staat tegenover dat criminelen dat ook kunnen doen, merkt TechCrunch op.

Tot nu toe versleutelde Apple de kernelcache van zijn mobiele besturingssysteem steevast en de testversie van iOS 10 is de eerste keer dat het niet gebeurt. De kernelcache is een bestand in img4-formaat, bestaande uit de kernel zelf en alle extensies.

Dat de kernelcache nu niet langer versleuteld is, betekent niet dat gebruikers automatisch alle info te zien krijgen. De tool Joker, die al jaren gebruikt kan worden om de kernelcache van iOS-apparaten in te zien, vermeldt in de changelog voor de iOS 10-versie dat er bij het simpel exporteren van de onversleutelde kernelcache nog altijd elementen niet te zien zijn. In tegenstelling tot wat sommige media melden, heeft Apple de kernel niet opengesteld of opensource gemaakt. Het gaat louter om het niet versleutelen van de al gecompileerde kernelcache, die in de vorm van een img4-bestand in iOS staat.

Reacties (81)

[Trebaruna]

"Bovendien kunnen beveiligingsonderzoekers nu makkelijker rondsnuffelen in de code, en eventuele kwetsbaarheden opsporen en doorgeven aan Apple."

Apple claimt niet dat het makkelijker is om rond te snuffelen, alleen dat het geen beveiligingsprobleem is: "The kernel cache doesn’t contain any user info, and by unencrypting it we’re able to optimize the operating system’s performance without compromising security"

Vervolgens:
"Daar staat tegenover dat criminelen dat ook kunnen doen, merkt TechCrunch op."

Okee, ja, dat zou kunnen, maar in ditzelfde artikel:
"De tool Joker, die al jaren gebruikt kan worden om de kernelcache van iOS-apparaten in te zien (...)"

Dus die versleuteling deed al niks! Onderzoekers konden gewoon dit Joker-tooltje gebruiken! Waarom dan alle ophef?

[AntiSocial]

Wat ik eruit begrijp levert de Joker tool in iOS10 _unencrypted_ compiled data. Daarvoor was het _encrypted_ compiled data. Iets dat is gecompileerd is met de juiste tools, kennis en kunde nog wel wat mee te doen. Wat hier eventuele risico's van zijn...geen idee

[Verwijderd]

Ze slaan nog altijd de bal mis door geen bug Bounty programma te organiseren.
Bij microsoft krijg je duizenden euro's voor een werkende kernel exploit. Bij apple krijg je nul euro.
Als je dan weet dat zimperium een miljoen euro uitloofde voor een iOS exploit, dat dan de keuze snel gemaakt is.
FBI en CIA betalen ook graag voor zo'n exploit. Onderzoekers kiezen dus voor deze grote bedragen ipv een leuke naamvermelding in de changelogs met 0 euro opbrengst. En dat is wat Apple niet zo graag heeft, maar eigenlijk zelf In de hand werkt.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 03:54]

[xleeuwx]

Tenzij ze hier gewoon mensen voor inhuren. Bij bounty program moet je maar hopen dat mensen aan de slag gaan met je kernel. Als Apple mensen inhuurt weten ze zeker dat het gebeurt.

[Iblies]

Zo werkt het niet.

Vaak zijn het toevalligheden wat een redelijk bekwaam persoon opvalt.
Mooi voorbeeld was een foutje bij Facebook;
nieuws: Ontwikkelaar demonstreert Facebook-bug via account Mark Zuckerberg

Als je er een prijs op gaat plakken zullen bijvoorbeeld studenten sneller de kernel eens een keer bekijken.
De kans dat een fout meerdere malen opvalt is daardoor groter, dus al zou je die op de zwarte markt verkopen dan is het maar voor korte duur.


Screenen door een extern bedrijf klinkt mooi, je krijgt een stapel met papiertje waar stempeltjes op staan, alleen is het geen garantie. Die lopen een lijstje af in enkele dagen en daar zul je het mee moeten doen.
Mensen die er zelf aan hebben gewerkt zullen er blind voor zijn, de enkele persoon die wordt aangenomen om fouten te achterhalen, daar is het systeem te complex voor.
Een goed bounty-programma haal je heel veel kennis uit de breedte die je zelf nooit in dienst kunt hebben.

[EgMaf]

Bug Bounty hunt komt echt niet in plaats van zelf bugbashen (intern en met inhuur). Of dacht je nou echt dat Microsoft zelf niet zoekt en afwacht tot iemand iets vindt en aanmeldt?

[Laloeka]

Dat lijkt wel de richting waar Microsoft naartoe gaat. Met het Microsoft Insiders programma kun je de laatste releases testen van Windows 10.

Natuurlijk zullen ze zelf nog zat tests uitvoeren, vooral voor de belangrijkste componenten van hun besturingsysteem.

Maar het is voor Microsoft veel voordeliger om gewoon een groepje fans een half jaar voor de officiële release al met de nieuwste releases te laten spelen en een feedback formulier opzetten. Dan stop je er een disclaimer bij die neerkomt op "use at own risk and report bugs when found" en je hebt een gratis testplatform.

[Rodrigo]

Een goede vriend van me werkt voor 1 van de bedrijven dewelke door Microsoft ingehuurd worden om bugs uit Windows 10 te halen en code reviews te doen.
Geloof me, ze testen Windows 10 grondig, maar hebben daarboven ook nog een bounty programma voor de bugs die toch door de reviews geraken

[nlvmark]

Naast wat lblies noemt is er ook nog het effect dat je kwaadwillende hackers misschien kan overhalen om de bug te melden i.p.v. te verkopen als de zwarte markt prijs lager is dan de bounty.

[xleeuwx]

En wat ik bedoel is dat juist die mensen gewoon ingehuurd worden door Apple om intern met wat meer data / voorkennis het systeem te pentesten.

[nlvmark]

Dat is op zichzelf een heel goed plan.
Het nadeel is dat zelfs Apple niet de middelen heeft om hele legers hackers in te zetten. Als je een vast team van hackers/beveiligingsexperts hebt kun je veel fouten eruit halen. Met een bug bounty program vergroot je de kans dat als er fouten doorheen glippen dat deze alsnog worden opgepakt.

Is het beveiligingsteam zo goed dat er geen fouten doorheen glippen dan is er alsnog niks mis met een bug bounty program, het kost je dan namelijk helemaal niks.

[AntiSocial]

Ik denk wel dat hier ook geldt dat meer mensen niet per sé meer bugs of vulnerabilities betekent. Sommige dingen worden bij toeval gevonden, omdat men iets geks doet of gekke omstandigheden. Dingen als side channel attacks zal Apple ook wel weinig mee doen intern, denk ik. Deze toevallige ontdekkingen moet je blijven aanmoedigen, vind ik

[royb3]

Beide kunnen prima.

[Genius-General]

Betekend dit dan ook dat een jailbreak piece of cake word?

[RedPixel]

In ieder geval een stuk makkelijker

[lepel]

Laten we het hopen. Laatst mijn iPhone 6 geupdate naar iOS 9 vanaf een gejailbreaked iOS 8 in afwachting van de nieuwe iPhone in september (ik kan meestal exact verlengen wanneer de nieuwe iPhone bekend gemaakt word). Benieuwd wat ze met de nieuwe telefoon gaan doen, en dan vrij snel weer een jailbreak zou heel fijn zijn.

Ik mis toch wel echt een paar hele fijne tweaks als SwipeSelection, TinyBar en uiteraard mijn gpSPhone.

[ismilyfox]

Of voor FBI?

[Firefly III]

Dit is een mooi voorbeeld van hoe "CIA" ook "andersom" toegepast wordt. Het gaat dan vooral om de A, van availability.

De availability beschrijft niet dat een systeem altijd online moet zijn, of lange uptimes moet hebben, maar dat gegevens beschikbaar moeten zijn als ze nodig zijn. Dat is moeilijk(er) met encryptie, want je moet de sleutel paraat hebben op het juiste moment en de juiste plaats.

Door de kiezen voor géén encryptie voldoe je dus ook aan de "availability".

[Tozz]

Opzich waar, maar door encryptie weg te halen voldoe je wellicht minder aan de C (Confidentiality)? Immers, de kans dat een derde nu data kan lezen die het niet zou mogen lezen is groter?

Kortom, heeft dit wel zin? Ene punt sterker maken door het andere punt af te zwakken?

[Firefly III]

Apple beargumenteert, zoals in het stukje te lezen is, dat er geen confidential data in de kernel cache staat.

[RobbieB]

Nee, Apple beweert dat er geen gebruikersdata in de kernel staat. Dat wil niet zeggen dat deze data niet confidentieel is. dat ze het nu openbaar beschikbaar stellen, is in ieder geval een indicatie dat ze de confidentialiteit van de kernel niet meer zo hoog inschatten als voorheen.

[Ruw ER]

iOS gaat steeds meer op android lijken, en dit is weer een voorbeeld. Er kan steeds meer aangepast worden per release van iOS, en er wordt steeds meer open gegooid, zowel voor 3rd party developers, als delen van het systeem zelf, zoals deze kernel.
Niet verkeerd, zeker niet, maar het is wel grappig hoe android en iOS naar elkaar toe groeien. Android wordt steeds mooier, stijlvoller, en veiliger zoals iOS, en iOS kopieert ieder jaar weer functies van android, denk aan custom keyboards, soort van widgets, raise to wake, betalen met nfc, en dingen als maps en siri worden nu opengesteld voor developers. Over een paar jaar wordt verschillen vinden lastig.

[xoniq]

Dat 'naar elkaar groeien' is ook het eerste wat ik ervaar de afgelopen jaren.
Waar Android steeds meer gesloten gaat worden, word iOS steeds meer open gegooid (dan wel met beleid en veilige systeem API's; mag gezegd worden).

[monojack]

Het verschil zal ook nog binnen een paar jaar te merken zijn. Apple heeft sinds een tijdje een feature die lastig te kopiëren is voor Google. Namelijk privacy, Google moet zijn business model omgooien om die feature te kunnen kopiëren. Heel slim gezien van Apple.

[mkools24]

99% van de gebruikers boeit privacy niets zolang alles maar gewoon goed werkt. Dat geldt voor mij ook trouwens, als ik fileinformatie kan zien doordat ik aan Google mijn locatie en huidige snelheid doorgeef en iedereen dat doet, is dit een gemak wat voor mij boven privacy gaat. Hetzelfde dat Google mijn mail doorspit en mij vluchtinformatie geeft of wanneer ik een rekening moet betalen, super makkelijk maar inderdaad wel privacy gevoelig.

Verder gebruiken de meeste Apple users ook facebook, whatsapp, twitter etc en weten overheden precies waar je heen surft en waar je toestel zich bevindt dus van privacy is allang geen sprake meer. Vanaf het moment dat jij besluit met een smartphone rond te gaan lopen geef je je privacy op, zo simpel is het.

Hoe dan ook jij ziet het als een unique selling point maar veel mensen zal het weinig tot niets interesseren.

[Verwijderd]

Helemaal mee eens. Apple kan het weliswaar commercieel benutten, en dat zal ook nog werken ook (want iedereen vindt z'n privacy belangrijk, maar vrijwel niemand handelt er naar). Maar wat Google doet is heel erg slim: ze bieden zulke nuttige applicaties dat mensen liever die applicaties gebruiken dan dat ze hun gegevens afschermen. Het voorbeeld wat je noemt over fileinformatie is er maar 1, maar er zijn zoveel hele handige functies die het leven makkelijker maken. En het is daarbij ook goed om te beseffen dat het leven van 99,9999% van de mensen zo oninteressant is dat het Google en anderen niks kan schelen wat je doet.

[Ruw ER]

Heb je gelijk in, dat is nog een groot verschil. Is ook 1 van de redenen neem ik aan dat iphones relatief duur zijn. Er dient betaald te worden voor zaken die google betaald met jou persoonsgegevens. Vergelijk bijvoorbeeld de s7 met de 6s. De s7 heeft een beter, dus duurder scherm, camera, meer opslaggeheugen, is waterdicht, er zijn vast meer zaken. Toch is is s7 goedkoper als een 6s, en dat heeft te maken met een ecosysteem dat op een andere manier onderhouden wordt, is mijn gok.
Toch graviteren de besturingssystemen naar elkaar toe. Vanuit android kant naar veiligheid, en uiterlijk, en vanuit iOS kant naar functies. Er wordt op die punten genoeg van elkaar afgekeken.

[mkools24]

Dat heeft ermee te maken dat de S7 geen Apple logo draagt meer niet. Bij Apple is de premium prijs marketing. Je betaald gewoon het verschil voor het logo, hoe denk je dat Apple iets van 150 miljard op de bank heeft staan momenteel?

[Nogne]

Niet alleen het logo, het heeft ook te maken met de software en ondersteuning. Nu is het zo dat Samsung met zijn flagship nog redelijk ondersteuning bied, maar het valt in het niets bij Apple/iOS.

Daarbij zoals boven word aangegeven is Apple een stuk privacy vriendelijker, en Samsung draait op Android. Android word voornamelijk ontwikkeld door een extern bedrijf, iOS word door Apple zelf ontwikkeld. Daar gaat ook heel veel geld in zitten.

Bij Apple en Samsung betaal je voor het logo.

[mkools24]

Naja Samsung ontwikkelt ook een hoop zelf op Android natuurlijk.

[AlphaBlack_NL]

Als je het alleen logo veranderd zit je nog steeds vast aan Android en Touchwizz. Je vergelijking gaat meer op voor Samsung ivm Huawei of Xiaomi, Oneplus aangezien dat allemaal Android is met grotendeels zelfde specs vaak Snapdragon etc.

[Xthemes.us]

Dat geld gaat gewoon richting de bankrekening van Apple, niet richting je privacy of andere leuke dingen waar je mogelijk plezier van hebt.
Kijk simpelweg naar de winstmarge van Apple, binnen de smartphone bij verre de hoogste.

De iPhone(s) doordat ze in enorme oplagest worden gemaakt vergeleken met de meeste Android telefoons zijn sowieso al goedkoop in productie, en daarnaast is de prijs nog hoger in plaats van competitief - ofwel er wordt dubbel aan verdiend .

[Pendora]

Het zal me niks verbazen als dit alleen tijdens de beta is zodat er nu exploits worden gevonden die ze kunnen verhelpen in het eind product

[Jorgen]

Dan is het leed echter ook al geschied. Iedereen die kwaad wil, heeft de code ook in kunnen zien.

[CAPSLOCK2000]

Ik had nog nooit van Apple's kernelcache gehoord en heb het dus even opgezocht. Ik ging er van uit dat het iets met RAM-geheugen en disk-caches te maken zou hebben maar dat blijkt niet te kloppen.

The kernelcache is basically the kernel itself as well as all of its extensions (AppleImage3NORAccess, IOAESAccelerator, IOPKEAccelerator, etc.) into one file,

Dat is niet iets waar ik de term 'cache' voor zou gebruiken maar dat zal wel historisch zo gegroeid zijn.

[PTR]

Grappige opmerking van apple vrind Stefan Esser:

Nobody seems to question why Apple "intentionally" left 64 bit kernel unencrypted but "intentionally" encrypted 32 bit kernel in iOS beta 1
"We do not encrypt for performance reasons... That is why we still encrypt on the old slow devices but not on the fast 64 bit devices"

https://twitter.com/i0n1c/status/745887254053265410

[:murb:]

Weet niet of het er direct mee te maken heeft, maar in de unlock zaak van de iPhone 5C werd genoemd dat het technisch ontwerp van de 5S en nieuwer veiliger was (de 5C is een iPhone 5 met een kleurtje). Misschien maakt het voor die telefoons dus nog wel degelijk uit of de kernel geencrypt is (al zijn er (dure?) workarounds voor beschikbaar), maar is het technisch ontwerp van de 5S en hoger (allen 64 bit) dusdanig beter dat de kernel daarvan wel unencrypted zijn? Al zag ik ook liever niet dat ze het terugdraaien, het is voor mij als leek op dit gebied lastig om er over te oordelen.

[TweakJunior]

Kan je dit uitleggen?
Ik snap het niet helemaal.

[Hedva]

Nou, ik weet het niet zaker maar ik denk het volgende;
Van encrypten wordt het device langzamer (volgens Apple dus).

Alleen de iPhone 5S is van de iPhones volgens mij 64-bit.

Als je oude devices encrypt (wat volgens apple dus niet nodig is) zijn ze nog langzamer. De nieuwere lijken daar nog veel sneller door. Dus nog meer reden om een nieuwe te kopen

Hoe het met de iPad zit, heb werkelijk geen idee.

[Reactie gewijzigd door Hedva op 25 juli 2024 03:54]

[TweakJunior]

Maar de 5s,6,6s krijgen dan wel een performance boost?

[kevinr1]

Het droge van dit verhaal is:
Apple liegt. Waarschijnlijk is een medewerker vergeten de encryptie aan te zetten.

Want het gekke deze opzet is:
Voor 64-bits is encryptie uitgezet.
Voor 32-bits is encryptie aangezet.

Maar Apple geeft aan dat ze de encryptie 'express' hebben uitgezet voor performance redenen. Terwijl de 32-bit devices juist lijden onder performance problemen. Logischer zou zijn om het voor de 32-bit uit te zetten.

Hiermee zullen de 32-bit apparaten tragen aanvoelen door de eindgebruikers met iOS 10. Zo zullen zij zich opgedrongen voelen om hun device te upgraden.


Eén van de positieve bijkomstigheden van dit verhaal is een grotere kans op een Jailbreak. Omdat encryptie uitstaat kan bijvoorbeeld de werking van de KPP module achterhaald worden.

[Reactie gewijzigd door kevinr1 op 25 juli 2024 03:54]

[supersnathan94]

Welke 32bit apparaten? alleen de 4S heeft geen 64Bit SOC en die is al te traag om echt als smartphone te gebruiken. Als starter of om alleen mee te bellen en appen is het prima.

op de iPad is het hetzelfde verhaal. Op de iPad 4 na zijn de apparaten al zo traag dat je dat echt niet gaat merken. Vooral de iPad 3 is tergend langzaam. Ik heb zelf de mini 1, mini 2, iPad 2, iPad 3 en iPad air 2 thuis liggen en van alle apparaten is de iPad 3 veruit het traagst. De mini 1 gaat geen upgrade meer krijgen en de iPad 3 geef ik em niet al zou die het wel ondersteunen. Nog meer traagheid kan ik niet handelen.

Al met al is dit gewoon spijkers op laag water zoeken. De verschillen met of zonder encryptie ga je pas echt merken op apparaten die dat ook echt merkbaar kunnen maken. Bij een iPad air 2 of PRO is een tiende van een seconde langer wachten erg veel in verhouding terwijl dit bij een iPad 3 echt niet meer uitmaakt.

[dennissimeau]

Dat is niet waar. Pas vanaf iPhone 5s wordt er een 64-bit SoC gebruikt.

[supersnathan94]

Klopt ja de A7 zat pas in de 5S. Foutje XD.

Maar dan nog. Op een iPhone 5 ga je het echt niet merken of het nou wel of niet aan staat. het duurt toch wel lang.

[kevinr1]

"Ik heb zelf de mini 1, mini 2, iPad 2, iPad 3 en iPad air 2 thuis liggen".
Wauw..

[supersnathan94]

Zijn niet allemaal van mij hoor . M'n moeder had eerst ook nog een Air1 van het werk maar die heeft ze gisteren weer ingeleverd. Tot nu toe heb ik alle iPads op de 4, mini 3/4 en pro's na in huis gehad.

[Probook8979]

Wat is een kpp module?

[Vexxon]

Betekent dit dat dat ze de fbi geen backdoor gegeven hebben maar wel hebben gezegd waar ze de sleutel kunnen vinden?

[Aaargh!]

Lijkt me heel sterk. Zeker gezien ze net een crypto guru hebben aangenomen

[Reactie gewijzigd door Aaargh! op 25 juli 2024 03:54]

[ELD]

Sleutels zijn makkelijk te verbergen in random crypto grade data. Het is voor Apple om daarom handiger om encryptie te blijven gebruiken als ze dit hadden willen doen.

[Macshack]

Dit is een goede trend. Om je systeem zo veilig mogelijk te maken moet beveiliging zo min mogelijk complex zijn en de risico's zo duidelijk mogelijk in beeld zijn. Bijgeloof en onduidelijkheid dragen alleen maar bij aan onveiligheid. Het feit dat Apple dit nu doet betekend dat ze een beter beeld hebben van wat beveiligd moet worden en wat daadwerkelijk de risico's zijn. Ook betekend het dat ze een duidelijke visie hebben omtrent welke gegevens waar aanwezig horen te zijn. Het klinkt daarom vrij logisch dat een kernel geen persoonlijke data zou moeten huisvesten.

[dormamu]

Met alle respect, als je kijkt naar de datum dat ontdekt is dat de kernel niet versleuteld was, dat Apple toen zich weer hield van commentaar en de tijd dat het geduurd heeft dat Apple wel met een verklaring kwam dan kan ik niet aan de indruk ontkomen dat dit persbericht meer damage control dan dat ze bewust de kernel onversleuteld hebben gedeeld.

Als bewust was geweest had Apple het echt wel als een 'one last thing' gebracht

[Aaargh!]

Hoe denk je dat zoiets per ongeluk gaat ? Het lijkt me extreem onwaarschijnlijk dat iemand met de hand onderdelen v/h OS encrypt bij elke build. Nee, zoiets doe je autonatisch en vergt dus ook een opzettelijke aanpassing van je build scripts.

[dormamu]

Hoe denk je dat zoiets per ongeluk gaat ? Het lijkt me extreem onwaarschijnlijk dat iemand met de hand onderdelen v/h OS encrypt bij elke build. Nee, zoiets doe je autonatisch en vergt dus ook een opzettelijke aanpassing van je build scripts.

Dus jij denkt dat Apple intern de kernel encrypted heeft als ze aan het ontwikkelen zijn? Ik beweer het tegenovergestelde dat de kernel intern per definitie decrypted is en dat Apple dus bij elke build een bewuste handeling aan het einde van hun ontwikkelproces voordat de bèta's worden uitgestuurd doet zodat de kernel encrypted de deur uitgaat. Deze laatste stap is waarschijnlijk per ongeluk overgeslagen.

[Sircuri]

Dat is niet wat @Aaargh! zegt. Hij zegt dat het build proces automatisch de versleuteling doet. ik denk inderdaad niet dat het interne build proces de kernel encrypt, maar zodra ze de "release build" knop indrukken er wel automatisch een encrypted versie van de kernelcache gemaakt wordt.

Waar dus de redenering vandaan komt dat het bedrijf zo'n grove fout zou maken met het builden, snap ik helemaal niet. Dit is allemaal geautomatiseerd en komt geen mens aan te pas.
Ik heb natuurlijk geen kijk op het ontwikkelproces van Apple, maar zelfs wij intern binnen ons bedrijf doen dit geautomatiseerd. Elke vrijdag, druk op de knop en na een half uur staat er een nieuwe build klaar om getest te worden inclusief release notes en alles.

[Aaargh!]

Geen enkele serieuze software developer zou zo werken, zeker niet voor je release builds. Ik denk dat je compleet onderschat hoe complex het is om iets als iOS te bouwen. Ik kan je verzekeren dat er geen enkele handmatige stap aan te pas komt, dat zou extreem amateuristisch zijn. Bovendien zou je dan in elke release wel wat mis zien gaan.

[vinsterdamus]

Het feit dat het voorheen altijd wel versleuteld was geeft voor jou niet aan dat het hier wel gaat om opzet? Het kost tijd en moeite om er voor te zorgen dat het niet versleuteld is wanneer dat voorheen wel altijd zo is geweest. Het lijkt mij sterk dat ze per ongeluk tijd geïnfesteerd hebben om dit te veranderen.

Sowieso is het niet echt een ding voor een "one last thing", technische veranderingen die niet bijdragen aan de gebruikerservaring zijn niet echt noemenswaardig voor een conferentie ook al is het een developers conferentie.

[dormamu]

Het feit dat het voorheen altijd wel versleuteld was geeft voor jou niet aan dat het hier wel gaat om opzet?

De visboer levert mij al 5 jaar elke week verse vis. Vandaag levert hij plotseling bedorven vis. Dit deed hij anders nooit dus het moet een bewuste keuze van hem geweest zijn.
Ik vind het trouwens ook een vreemde aanname dat er van uit wordt gegaan dat Apple intern met een encrypted kernel werkt. Dus Apple pas nooit zijn kernel aan? Het is logischer dat die intern decrypted is.

Sowieso is het niet echt een ding voor een "one last thing", technische veranderingen die niet bijdragen aan de gebruikerservaring zijn niet echt noemenswaardig voor een conferentie ook al is het een developers conferentie.

Volgens heb je over de knipoog heen gelezen

[Jeroen73]

Een visboer met klaarblijkelijk minimaal vijf jaar ervaring herkent bedorven vis vanaf kilometers, dus als hij jou dat toch levert kan het inderdaad niet anders dan dat het een bewuste keus is geweest

[Clifdon]

Ik vind dat je vergelijking meer iets zou moeten zijn in de vorm van:
De visboer levert mij al 5 jaar elke week verse verpakte vis. Vandaag levert hij plotseling vissticks.

Bedorven hoeft hij niets aan te doen dat gaat vanzelf en hij hoeft het niet te merken.
Nu moet de visboer de verpakte vis uitpakken om vervolgens visticks te staan maken. Dat is een behoorlijk bewust proces net als bij Apple.

[Ocirina]

Mag ik vragen of jij een software ontwikkelaar bent en of je weet hoe dit soort dingen te werk gaan?

Denk je dat meer dan 20 mensen vergeten om zo'n belangrijk component te versleutelen? En met 20 mensen bedoel ik meer dan 20 ontwikkelaars die zo'n build opleveren.

[Reactie gewijzigd door Ocirina op 25 juli 2024 03:54]

[sjongenelen]

Alsof je een build met de hand doet echt niet hoor

[Ocirina]

Haha, dat is ook precies wat ik wil bereiken. Dit is een bewust aanpassing geweest in de buildconfig of build-step.

[vinsterdamus]

Sowieso schrijven ze hier ook testen voor om überhaupt een build door een ci/cd straat te krijgen. Bij ons wordt 95% test coverage gehanteerd, Apple zal vast ook hier aan komen zo niet meer dus je kan het niet zomaar "vergeten" zijn.

[Ocirina]

Nee, dat is ook het punt wat ik wil maken. Zoiets belangrijks vergeten ze niet. Zijn we het daar iig. over eens!

[Macshack]

Kan iemand mij helpen om hier serieus op in te gaan?

[Verwijderd]

Wellicht moet je eens bellen met het Riagg. Ze hebben daar een hele goede stagiare

https://www.youtube.com/watch?v=iqdRYQUmkgQ

[Macshack]

Lol!!!

[DrSnuggles]

Al zullen zero-day exploits misschien sneller ontwikkeld worden die de kernel targeten. Als hackers van daaruit bij gebruikersgegevens kunnen, is die visie niet zo veel meer waard.

[Macshack]

Dat zou echt een enorm falen zijn. De kernel zit redelijk diep in het systeem. Als ze een beetje architectuur hebben toegepast dan weten de lager liggende delen niks van de hoger liggende delen. De CPU weet niets van de kernel. En de kernel zou niks moeten weten van de programma's die erop draaien. Dat is de reden dat er geen privacy gevoelige informatie in de kernel zou moeten rondzwerven.