[HN Gopher] Apple Platform Security (Jan 2026) [pdf]
___________________________________________________________________
Apple Platform Security (Jan 2026) [pdf]
Author : pieterr
Score : 124 points
Date : 2026-01-31 16:04 UTC (6 hours ago)
(HTM) web link (help.apple.com)
(TXT) w3m dump (help.apple.com)
| OGEnthusiast wrote:
| Glad there's still at least one tech company that cares about
| personal security / opsec.
| varispeed wrote:
| No mention of Pegasus and other software of such sort. Can latest
| iOS still be infected?
|
| There is no point creating such document if elephant in the room
| is not addressed.
| gjsman-1000 wrote:
| Why? The obvious conclusion is that Apple is doing everything
| in its power to make the answer "no."
|
| You might as well enumerate all the viruses ever made on
| Windows, point to them, and then ask why Microsoft isn't
| proving they've shut them all down yet in their documents.
| varispeed wrote:
| That analogy misses the asymmetry in claims and power.
|
| Microsoft does not sell Windows as a sealed, uncompromisable
| appliance. It assumes a hostile environment, acknowledges
| malware exists, and provides users and third parties with
| inspection, detection, and remediation tools. Compromise is
| part of the model.
|
| Apple's model is the opposite. iOS is explicitly marketed as
| secure because it forbids inspection, sideloading, and user
| control. The promise is not "we reduce risk", it's "this
| class of risk is structurally eliminated". That makes
| omissions meaningful.
|
| So when a document titled Apple Platform Security avoids
| acknowledging Pegasus-class attacks at all, it isn't
| comparable to Microsoft not listing every Windows virus.
| These are not hypothetical threats. They are documented,
| deployed, and explicitly designed to bypass the very
| mechanisms Apple presents as definitive.
|
| If Apple believes this class of attack is no longer viable,
| that's worth stating. If it remains viable, that also
| matters, because users have no independent way to assess
| compromise. A vague notification that Apple "suspects"
| something, with no tooling or verification path, is not
| equivalent to a transparent security model.
|
| The issue is not that Apple failed to enumerate exploits.
| It's that the platform's credibility rests on an absolute
| security narrative, while quietly excluding the one threat
| model that contradicts it. In other words Apple's model is
| good old security by obscurity.
| gjsman-1000 wrote:
| Words words and more words, new levels of verbosity even
| for a hacker, to say Apple has a weakness and isn't saying
| they've patched it with certainty; as though nation-state
| spyware can be conjured on demand from the heavens until
| governments throw up their hands and say "curses, you've
| fixed everything, we surrender." Even if there actually
| were no bugs remaining, I certainly wouldn't sign an
| affidavit saying no bugs will ever be found in the future.
| Retr0id wrote:
| don't worry, they set the allow_pegasus boolean to false
| goalieca wrote:
| Apple did create a boolean for that. They call it lockdown
| mode.
|
| > Lockdown Mode is an optional, extreme protection that's
| designed for the very few individuals who, because of who
| they are or what they do, might be personally targeted by
| some of the most sophisticated digital threats. Most people
| are never targeted by attacks of this nature. When Lockdown
| Mode is enabled, your device won't function like it typically
| does. To reduce the attack surface that potentially could be
| exploited by highly targeted mercenary spyware, certain apps,
| websites, and features are strictly limited for security and
| some experiences might not be available at all.
| varispeed wrote:
| If Pegasus can break the iOS security model, there's no
| reason to think it politely respects Lockdown Mode. It's
| basically an admission the model failed, with features
| turned off so users feel like they're doing something about
| it.
| jkubicek wrote:
| Lockdown mode works by reducing the surface area of
| possible exploits. I don't think there's any failures
| here. Apple puts a lot of effort into resolving web-based
| exploits, but they can also prevent entire classes of
| exploits by just blocking you from opening any URL in
| iMessage. It's safer, but most users wouldn't accept that
| trade-off.
| varispeed wrote:
| Claiming reduced attack surface without showing which
| exploit classes are actually eliminated is faith, not
| security.
|
| And Lockdown Mode is usually enabled _after_ user
| suspects targeting.
| goalieca wrote:
| If you did RTFA for this story, you'll see on page 67
| what I pasted with a link to the support article
| describing to end users exactly what's blocked. It does
| greatly reduce the attack surface.
| wat10000 wrote:
| Pegasus isn't magic. It exploits security vulnerabilities just
| like everything else. Mitigating and fixing those
| vulnerabilities is a major part of this document.
| random_duck wrote:
| Wow, this is hardcore (pun intended).
| buildbot wrote:
| 262 pages!!! Pretty interesting to see how the different SoCs
| have evolved security wise over time.
| easton wrote:
| Web version: https://support.apple.com/guide/security/welcome/web
| sonu27 wrote:
| That's Dec 2024
| modeless wrote:
| Then they turn around and upload your iMessages to their own
| servers in a form that they can read, breaking their own E2EE.
| Google Messages fixed this issue a long time ago. Why hasn't
| Apple? https://james.darpinian.com/blog/apple-imessage-encryption
| runjake wrote:
| This is your blog post, so I'll ask you a question. What are
| you trying to state in Belief #1? The message is unclear to me
| with how it's worded: > In this table, in the
| "iCloud Backup (including device and Messages backup)" row,
| under "Standard data protection", > the "Encryption"
| column reads "In transit & on server". Yes, this means that
| Apple can read all of your messages > out of your iCloud
| backups.
|
| In addition to the things you mentioned, there's certainly a
| possibility of Apple attaching a virtual "shadow" device to
| someone's Apple ID with something like a _hide_from_customer_
| type flag, so it would be invisible to the customer.
|
| This shadow device would have it's own keys to read messages
| sent to your iCloud account. To my knowledge, there's nothing
| in the security model to prevent this.
| shawnz wrote:
| The table has two categorizations: "In transit & on server"
| and "End-to-end". The former, which covers iCloud backups in
| the default configuration, is explicitly NOT end-to-end,
| meaning there are moments in time during processing where the
| data is not encrypted.
|
| However, iCloud backups actually are listed as "End-to-end"
| if you turn on the new Advanced Data Protection feature.
| digiown wrote:
| Or Apple can also push an update, which you can't refuse,
| that upon first message to iCloud just uploads your private
| key. It's a bit foolish to count on encryption implemented by
| the adversary you're trying to hide from. Of course, this
| will most likely only affect individuals targeted by state-
| level actors.
| shawnz wrote:
| IIRC Apple has attempted to implement some defences against
| this, for example by requiring the passcode to be inputted
| before an update can be installed to prevent another San
| Bernardino scenario. A cursory search indicates that they
| also have some kind of transparency log system for updates,
| but it seems to only apply to their cloud systems and not
| iOS updates.
| microtonal wrote:
| _This shadow device would have it 's own keys to read
| messages sent to your iCloud account. To my knowledge,
| there's nothing in the security model to prevent this._
|
| Matthew Green has some great posts about iMessage security.
| This one describes the key lookup issue:
|
| https://blog.cryptographyengineering.com/2015/09/09/lets-
| tal...
|
| Looking at the linked Apple Platform Security, it seems like
| the Apple Identity Service is still used as a public key
| directory.
| philsnow wrote:
| What is "Google Messages"? I can't count the number of articles
| people have written over time about how many first-party
| messaging apps Google themselves have put out (and then put
| down), not to mention what messaging apps get shoveled on by
| third-party android integrators.
|
| > the main reason a message wouldn't be properly end-to-end
| encrypted in Google's Messages app is when communicating with
| an iPhone user, because Apple has dragged their feet on
| implementing RCS features in iMessage
|
| (or with any other android user who isn't using a first-party
| device / isn't using this one app)
|
| > [...] Android's equivalent cloud backup service has been
| properly end-to-end encrypted by default for many years.
| Meaning that you don't need to convince the whole world to turn
| on an optional feature before your backups can be fully
| protected.
|
| You make it out to seem that it's impossible for Google to read
| your cloud backups, but the article you link to [0] earlier in
| your post says that "this passcode-protected key material is
| encrypted to a Titan security chip _on our datacenter floor_ "
| (emphasis added). So they have your encrypted cloud backup, and
| the only way to get the key material to decrypt it is to get it
| from an HSM in their datacenter, every part of which and the
| access to which they control... sounds like it's not really any
| better than Apple, from what I'm reading here. Granted, that
| article is from 2018 and I certainly have not been keeping up
| on android things.
|
| [0] https://security.googleblog.com/2018/10/google-and-
| android-h...
| modeless wrote:
| HSMs are designed to protect encryption keys from everyone
| including the manufacturer. Signal trusts them for their
| encryption features. It's the best security possible for E2EE
| backups with passcode recovery, and Apple does it too for the
| subset of data that they do real E2EE backups on, like
| Keychain passwords. Characterizing using an HSM to implement
| E2EE securely as "not any better than" just giving up on E2EE
| for messages backups is ridiculous.
| philsnow wrote:
| The HSMs that Signal and Apple are using are on-device
| though. Yes you still have to trust Signal / Apple to not
| exfil your key matter once decrypted by the HSM, but I
| submit that that is materially better than having the HSMs
| be hosted in a datacenter.
| modeless wrote:
| Signal and Apple and Google all use HSMs in datacenters
| as well as on device.
| TheNewsIsHere wrote:
| You can enable Advanced Data Protection to address that issue
| with iMessages.
|
| Giving users an option between both paths is usually best. Most
| users care a lot more that they can't restore a usable backup
| of their messages than they do that their messages are
| unreadable by the company storing them.
|
| I used to work at a company where our products were built
| around encryption. Users here on HN are not the norm. You can't
| trust that most users will save recovery codes, encryption seed
| phrases, etc in a manner that will be both available and usable
| when they need them, and then they tend to care a lot less
| about the privacy properties that provides and a lot more that
| they no longer have their messages with {deceased spouse, best
| friend, business partner, etc}.
| modeless wrote:
| > Apple can still read any message you exchange with
| practically anyone through _their_ iCloud backups, since they
| are overwhelmingly likely to have backups enabled and
| overwhelmingly _un_ likely to have proactively enabled the
| non-default "Advanced Data Protection" feature.
|
| > They could have implemented iMessage to not backup messages
| from people who enabled ADP, but they didn't. They won't even
| inform you when your conversation partner has uploaded your
| messages to Apple's servers in a form that Apple can read.
|
| > Android's equivalent cloud backup service has been properly
| end-to-end encrypted by default for many years. Meaning that
| you don't need to convince the whole world to turn on an
| optional feature before your backups can be fully protected.
|
| > Apple's stated reason for not enabling end-to-end
| encryption on iCloud backups by default is that it would
| cause data loss when users lose their devices. But Google's
| implementation avoids this problem. Furthermore, Apple does
| do end-to-end encryption by default on other critical
| information that would be painful to lose, such as your
| account passwords stored in Keychain. So that excuse doesn't
| seem to hold water.
| whitepoplar wrote:
| Given that A19 + M5 processors with MIE (EMTE) were only recently
| introduced, I wonder how extensively MacOS/iOS make use of the
| hardware features. Is it something that's going to take several
| years to see the benefit, or does MIE provide thorough protection
| today?
| bri3d wrote:
| I think all of the kernel allocators and most (?) system
| processes in iOS 26 have MIE enabled, as does libpas (the
| WebKit allocator), so it's already doing quite a lot.
| armadyl wrote:
| I was just watching a video on this yesterday:
| https://www.youtube.com/watch?v=5McB6-2r-ds
|
| Apple's implementation of MTE is relatively limited in scope
| compared to GrapheneOS (and even stock Android with advanced
| security enabled) as it's hardware intensive and degrades
| performance. I imagine once things get fast enough we could see
| synchronous MTE enabled everywhere.
|
| It is curious at the moment though that enabling something like
| Lockdown Mode doesn't force MTE everywhere, which imo it
| should. I think the people who are willing to accept the
| compromises of enabling that would likely also be willing to
| tolerate the app crashes, worse performance etc that would come
| with globally enabled MTE.
| drnick1 wrote:
| But all the software is closed source, and there is little to no
| opportunity to verify all these security claims. You don't have
| the encryption keys, so effectively the data is not under your
| control.
|
| If you want to see security done well (or at least better), see
| the GrapheneOS project.
| digiown wrote:
| GrapheneOS also doesn't give you the encryption keys. If you
| run the official version, there is no way for you to extract
| the data from your device at all beyond what app developers
| will let you access. This means that you do not own the data on
| your device. The backups are even less effective than Apple's,
| although they say they will work on it.
|
| The developers also appear to believe that the apps have a
| right to inspect the trustworthiness of the user's device, by
| offering to support apps that would trust their keys [1],
| locking out users who maintain their freedom by building their
| own forks.
|
| It's disheartening that a lot of security-minded people seem to
| be fixated on the "AOSP security model", without realizing or
| ignoring the fact that a lot of that security is aimed at
| protecting the apps from the users, not the other way around.
| App sandboxing is great, but I should still be able to see the
| app data, even if via an inconvenient method such as the adb
| shell.
|
| 1. https://grapheneos.org/articles/attestation-compatibility-
| gu...
| zb3 wrote:
| For some reason they don't release userdebug versions which
| was a dealbreaker for me.. (the device should be secure, but
| not against me)
|
| But if you wish to build it from source, it could probably be
| a good option.
| digiown wrote:
| You can re-sign it using
| https://github.com/chenxiaolong/avbroot
|
| I don't currently have any root on the phone, but I reserve
| the right to add it or run the userdebug build at a later
| date
| armadyl wrote:
| > The developers also appear to believe that the apps have a
| right to inspect the trustworthiness of the user's device, by
| offering to support apps that would trust their keys [1],
| locking out users who maintain their freedom by building
| their own forks.
|
| That is not a bad thing. The alternative is not having apps
| that do these checks available on the platform at all. It's
| ridiculous that someone should expect that every fork of it
| should have that capability (because the average developer is
| not going to accept the keys of someone's one off fork).
|
| If there's anyone to blame, it should be the app developers
| choosing to do that (benefits of attestation aside).
|
| Attestation is also a security feature, which is one of the
| points of GOS. People are free to use any other distribution
| of Android if they take issue with it.
|
| Obviously I could be wrong here, this is just the general
| sentiment that I get from reading GOS documentation and its
| developer's comments.
| digiown wrote:
| > Attestation is also a security feature
|
| I don't actually disagree with this. The auditor is a
| perfectly valid use of it. It's good to be able to verify
| cryptographically _your_ device is running what it 's
| supposed to.
|
| The problem is when it transcends ownership boundaries and
| becomes a mechanism to exert control over things someone
| doesn't own, like your bank or government controlling your
| phone. It is one of the biggest threats to ownership
| worldwide.
|
| Note also that getting "trusted" comes at the cost of other
| security features, such as spoofing your location securely
| to apps:
|
| https://news.ycombinator.com/item?id=44685283
| surajrmal wrote:
| You were not going to be able to use those apps anyways, so
| what does it matter to you? I, and I suspect many, agree with
| the purpose of attestation. The problems around it are
| strictly around establishing good ways to teach apps who they
| should trust, not around attestation itself. By putting your
| head in the sand, you'll never improve the situation.
| digiown wrote:
| > teach apps who they should trust
|
| Ah, the apps^Wgovernment (look at that page, most of it is
| government IDs) should be able to discriminate against me
| for daring to assert control over my own device. And
| GrapheneOS is saying:
|
| Hey government! We pinky promise to oppress the user just
| the same, but even more securely and competently than
| Google/Samsung!
|
| > what does it matter to you
|
| It shows that the developers maybe don't fully have your
| best interests at heart?
| amelius wrote:
| Yes, how can we verify this? Who says three-letter agencies
| have no access?
| rrgok wrote:
| Sometime I wonder how much overhead all these security features
| take in terms of performance.
|
| I would really like to see a benchmark with and without security
| measures.
| Retr0id wrote:
| It's not really possible to make a direct comparison, given
| that a big chunk of the features are baked into the silicon, or
| are architecture-level choices.
| TheNewsIsHere wrote:
| It's _technically_ possible, but it would be difficult and
| likely require breaching an NDA. A bit pedantic, perhaps, but
| it's out there.
|
| Apple makes available on a highly controlled basis iPhones
| which permit the user to disable "virtually all" of the
| security features. They're available only to vetted security
| researchers who apply for one, often under some kind of
| sponsorship, and they're designed to obviously announce what
| they are. For example they are engraved on the sides with
| "Confidential and Proprietary. Property of Apple".
|
| They're loaned, not sold or given, remain Apple's property,
| and are provided on a 12-month (optionally renewable) basis.
| You have to apply and be selected by Apple to receive one,
| and you have to agree to some (understandable but) onerous
| requirements laid out in an legal agreement.
|
| I expect that if you were to interrogate these iPhones they
| would report that the CPU fuse state isn't "Production" like
| the models that are sold.
|
| They refer to these iPhones as Security Research Devices, or
| SRDs.
| Retr0id wrote:
| These devices still _have_ all the security features.
| relium wrote:
| The ones I remember most affecting performance were zeroing
| allocated memory and the Spectre/Meltdown fix. Also, the first
| launch of a new app is slow in order to check the signature.
| Whole disk encryption is pretty fast today, but probably is a
| bit slower than unencrypted. The original FileVault using disk
| images was even slower.
| mcculley wrote:
| > Whole disk encryption is pretty fast today, but probably is
| a bit slower than unencrypted.
|
| Isn't whole disk encryption nowadays done in hardware on the
| storage controller?
| zb3 wrote:
| Protects the device well... against the owner of the device using
| it as they wish :)
| wcfrobert wrote:
| Apple's commitment to privacy and security is really cool to see.
| It's also an amazing strategic play that they are uniquely in the
| position to take advantage of. Google and Meta can't commit to
| privacy because they need to show you ads, whereas Apple feels
| more like a hardware company to me.
| bigyabai wrote:
| You know what's even cooler? Apple's commitment to hiding US
| federally-mandated backdoors for dragnet surveillance:
| https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...
| Apple has since confirmed in a statement provided to Ars that
| the US federal government "prohibited" the company "from
| sharing any information," but now that Wyden has outed the
| feds, Apple has updated its transparency reporting and will
| "detail these kinds of requests" in a separate section on push
| notifications in its next report.
| Noaidi wrote:
| That people fall for this corporate BS while Tim Cook is giving
| gold bars to Trump and dining and dancing with him When people
| are being murdered on the streets by ice is just amazing to me.
| OGEnthusiast wrote:
| Well that's what Americans voted for. So I don't think anyone
| cares that every CEO (definitely not just Tim Cook) is
| schmoozing with Trump.
| bigyabai wrote:
| > Well that's what Americans voted for.
|
| Americans are not one person.
|
| > So I don't think anyone cares
|
| Clearly they do.
|
| > every CEO (definitely not just Tim Cook) is schmoozing
| with Trump.
|
| Tim Cook was (supposedly) principled. I guess it's hard to
| pretend that you care about privacy or human rights while
| eating dinner next to bin Salman.
| OGEnthusiast wrote:
| > Tim Cook was (supposedly) principled. I guess it's hard
| to pretend that you care about privacy or human rights
| while eating dinner next to bin Salman.
|
| I guess if you thought he had principles then yeah that
| could be disappointing. Personally I've never tried to
| moralize corporations though, I just assume the only
| principle that every company and CEO operates by is
| whatever increases the stock price.
| Noaidi wrote:
| Funny that you think that people have free will under this
| zombie social media mind controlled Internet world we're
| living in.
|
| Besides Trump's approval ratings are worse than ever so I
| don't think people really got what they wanted, they got
| who they voted for not what they voted for.
| n8cpdx wrote:
| The Twinkie defense is alive and well, I see.
| bambax wrote:
| Yeah Americans voted for Trump. But that shouldn't prevent
| CEOs to show a spine. Tim Cook is no different from all the
| others, therefore Apple doesn't deserve any less contempt
| from us.
| vrosas wrote:
| You know this is just marketing right? Apple gives zero fucks
| about security. They just use it to lock competitors out of
| their gardens and preach a holier-than-thou attitude about it.
| candiddevmike wrote:
| All while slowly stuffing (more?) ads into their software.
|
| In a lot of ways Apple is as aligned to data privacy the same
| way other "platforms" are: to gatekeep the user data behind
| their ad service. It's better than selling your data, maybe,
| but you're still being tracked and monitored.
| isodev wrote:
| The worst part is since Apple is technically not a 3rd
| party, many of the rules don't apply to them even though
| they bring the same harm to the users. Did you notice the
| new "creative suite" has analytics with identities linked
| to your Apple account turned on by defend? Free
| Pages/Numbers is not so free anymore.
| dangus wrote:
| > Apple gives zero fucks about security.
|
| Hyperbole doesn't help your point. They definitely care about
| security, their profits depend on it.
| jtbayly wrote:
| modeless linked to this article earlier today:
|
| https://james.darpinian.com/blog/apple-imessage-encryption/
|
| My current understanding of the facts:
|
| 1. Google defaults to encrypted backups of messages, as well as
| e2e encryption of messages.
|
| 2. Apple defaults only to e2ee of messages, leaving a massive
| backdoor.
|
| 3. Closing that backdoor is possible for the consumer, by
| enabling ADP (advanced data protection) on your device.
| However, this makes no difference, since 99.9% of the people
| you communicate will not close the backdoor. Thus, the only way
| to live is to assume that _all_ the messages you send via
| iMessage will _always_ be accessible to Apple, no matter what
| you do.
|
| It's not like _overall_ I think Google is better for privacy
| than Apple, but this choice by Apple is _really_ at odds with
| their supposed emphasis on privacy.
| dd8601fn wrote:
| ADP isn't the default, and almost nobody who isn't a
| journalist/activist/potential target turns it on, because of
| the serious (potentially destructive) consequences.
|
| How does Google manage this, such every normie on earth isn't
| freaking out?
| buckle8017 wrote:
| Nobody expects their text messages to be backed up.
|
| They get deleted and people shrug.
| isodev wrote:
| > Apple's commitment to privacy
|
| We know now that it was all marketing talk. Apple didn't like
| Meta so they spun a bunch of obstacles. Apple has and would use
| your data for ads, models and anything that keeps the
| shareholders happy. And we don't know the half of the story
| where as a US corp, they're technically obliged to share data
| from the not-E2EE iCloud syncs of every iPhone.
| dangus wrote:
| Apple has ads. See the App Store, Apple Maps is also planning
| to roll out advertising.
| derbOac wrote:
| It's all tempered by them ultimately controlling what you can
| put on your phone though.
|
| As was demonstrated in LA, it's starting to have significant
| civil rights consequences.
| throwaway290 wrote:
| Security is pointless if platform allows 90% users to be
| social engineered into running code disabling that security
| ioasuncvinvaer wrote:
| Apple is an ad company now though
| baxtr wrote:
| Apple sells some ads yes. But it's a tiny fraction of their
| revenue.
|
| Would Google or Meta go bankrupt if they stopped selling ads?
| Yes. Apple wouldn't.
| bigyabai wrote:
| Apple would go bankrupt without US protectionist policy
| propping up their service revenue.
|
| That's pretty bad. Maybe not "reliant on ad monopoly" bad,
| but pretty close.
| porcoda wrote:
| In their revenue report this week out of $140B, services
| made up 30B. 140B-30B = 110B. Thats pretty far from
| bankruptcy.
| manuelabeledo wrote:
| Elaborate? Financial results say otherwise.
| avazhi wrote:
| What does whether they'd go bankrupt or not have to do with
| whether they're an ad company?
|
| They sell third party ads: companies unaffiliated with
| Apple pay Apple to advertise on Apple platforms.
|
| They're an ad company. Just because it's currently a small
| slice of their total revenue doesn't make it untrue.
| baxtr wrote:
| I mean if you don't care about details that's fine I
| guess. Let's call any company that sells and/or buys any
| amount of ads an "ad company". Let's put them all into
| one bucket and judge. That's super valuable.
| anon7000 wrote:
| What matters is that the parent comment said "Apple is an
| ad company now," as if that negated all the privacy and
| security stuff they do.
|
| Making some cash on ads doesn't _have_ to rely on
| targeted tracking. That only matters if ads are an
| existential part of your business, and without huge ad
| revenue growth, your company is dead.
| manuelabeledo wrote:
| I guess it's also a financial company, since they have a
| branded credit card?
| shepherdjerred wrote:
| Apple's ad revenue was 1% of its total in 2024. It was
| estimated to be 2-3% in 2025.
|
| https://www.apple.com/newsroom/pdfs/fy2024-q4/FY24_Q4_Consol.
| ..
|
| https://www.macrumors.com/2025/10/30/apple-4q-2025-earnings/
| eddyg wrote:
| I still like to encourage people to watch _all_ of
| https://www.youtube.com/watch?v=BLGFriOKz6U&t=1993s for the
| details (from Apple's head of Security Engineering and
| Architecture) about how iCloud is protected by HSMs, rate
| limits, etc. but _especially_ the timelinked section. :)
| bigyabai wrote:
| I still recommend _Mr. Fart 's Favorite Colors_ as a
| refutation, describing why all of these precautions cannot
| protect you in a real-world security model:
| https://medium.com/@blakeross/mr-fart-s-favorite-
| colors-3177... Unbreakable phones are coming.
| We'll have to decide who controls the cockpit: The captain?
| Or the cabin?
| eddyg wrote:
| Krstic: "Here's how we reduce the chance that even Apple
| can access or alter X, and here's how we can make that
| credible."
|
| Ross: "Even if you make X cryptographically airtight, the
| real fight becomes political/physical coercion: 'ship this
| or else.'"
|
| Those can both be true at the same time.
| epolanski wrote:
| I claim bs at this whole apple privacy thing, nothing but
| propaganda.
|
| Two years ago I was locked out of my MacBook pro.
|
| Then I just booted in some recovery mode and just..reset the
| password!?
|
| Sure macos logged me off from (most) apps and website, but
| every single file was there unencrypted!
|
| I swear people that keep boasting that whole apple privacy
| thing have absolutely no clue what they are talking about,
| nothing short of tech illiterate charlatans. But God the
| propaganda works.
|
| And don't start me on iMessage.
| n8cpdx wrote:
| You chose not to enable FileVault during setup. Probably
| because you were worried about being locked out and wanted an
| easy way to reset the password.
|
| Would you prefer that Apple did not give you the option to
| disable the security feature you disabled during setup?
| epolanski wrote:
| Ain't nobody paying attention, in any case it's still
| propaganda.
| willturman wrote:
| You can request a downloadable a copy of any/all of the data that
| Apple has associated with your account at
| https://privacy.apple.com.
|
| This apparently includes retrieving all photos from iCloud in
| chunks of specified size, which seems an infinitely better option
| than attempting to download them through the iCloud web interface
| which caps downloads to 1000 photos at a time at less than
| impressive download speeds.
| gumby271 wrote:
| It sucks that Apple decided to monitize iPhone the way they have,
| by controlling the owners ability to install software of their
| choosing. Ignoring the arguments one could make about this making
| it "more secure" it's clearly disrespectful to the power user
| that doesn't want to beg Apple's permission to use their
| computer. I'll grant them their security claims are sound, but
| it's hard to take them serious regarding privacy arguments.
|
| Our choices are either (A) an OS monitized by tracking user
| interaction and activity, or (B) monitized by owning the basic
| act of installing software on the device, both of these options
| suck and I struggle to give up the more open option for one that
| might be more secure.
| microtonal wrote:
| _Ignoring the arguments one could make about this making it
| "more secure" it's clearly disrespectful to the power user that
| doesn't want to beg Apple's permission to use their computer.
| I'll grant them their security claims are sound,_
|
| I wouldn't say they are sound. First, macOS provides the
| freedom to install your own applications (ok, they need to be
| signed and notarized if the quarantine attribute is set) and
| it's not the case that the Mac has mass malware infestations.
| Second, the App Store is full of scams, so App Store - safe,
| external - unsafe is a false dichotomy.
|
| Apple uses these arguments, but of course the real reason is
| that they want to continue to keep 30% of every transaction
| made on an iPhone or iPad. This is why they have responded to
| the DMA with a lot of malicious compliance that makes it nearly
| impossible to run an alt-store financially.
|
| (Despite my qualms about not being able to install apps outside
| the app store, I do think they are doing a lot of good work of
| making the platform more secure.)
| dan-robertson wrote:
| The OP is about security and you specifically ignore security
| when bringing up a common flamewar topic for which much
| discussion has already been had on this site. Perhaps such
| discussion could at least be limited to articles where it is
| less tenuously related.
| gumby271 wrote:
| I guess I bring it up in the sense that no matter how good
| their security is, it still sucks that Apple products are so
| hostile to their owners. It's hard to be impressed by their
| security work with the platform being what it is.
|
| Security, privacy, and ownership aren't equally separated in
| my mind.
| promiseofbeans wrote:
| They made C memory safe? This is a big thing to gloss over in a
| single paragraph. Does anyone have extra details on this?
|
| > On devices with iOS 14 and iPadOS 14 or later, Apple modified
| the C compiler toolchain used to build the iBoot bootloader to
| improve its security. The modified toolchain implements code
| designed to prevent memory- and type-safety issues that are
| typically encountered in C programs. For example, it helps
| prevent most vulnerabilities in the following classes:
|
| > * Buffer overflows, by ensuring that all pointers carry bounds
| information that's verified when accessing memory
|
| > * Heap exploitation, by separating heap data from its metadata
| and accurately detecting error conditions such as double free
| errors
|
| > * Type confusion, by ensuring that all pointers carry runtime
| type information that's verified during pointer cast operations
|
| > * Type confusion caused by use after free errors, by
| segregating all dynamic memory allocations by static type
| vsgherzi wrote:
| Sort of. From my understanding they've been heavily using clang
| with fbounds checks to insert checks into functions. I think
| there was work done to try to insert them into existing code as
| well. They memory tagging in new processors help avoid overflow
| exploitation. Maybe someone can jump in and add more details
| bri3d wrote:
| Many years ago. It's called Firebloom. I think it's similar in
| theory and lineage to Fil-C.
|
| https://saaramar.github.io/iBoot_firebloom/
| 1over137 wrote:
| >They made C memory safe?
|
| They made a dialect of C with bounds safety, see:
|
| https://clang.llvm.org/docs/BoundsSafety.html#overview
___________________________________________________________________
(page generated 2026-01-31 23:01 UTC)