Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Platform Security (Jan 2026) [pdf]

help.apple.com

Post reply on HN
Print view View original

71–80 of 205 posts

Re: Apple Platform Security (Jan 2026) [pdf]

#71

Post by philsnow »

modeless wrote: post #64
philsnow wrote: post #38

Earlier quoted context omitted.

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…

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 fo…

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.

Re: Apple Platform Security (Jan 2026) [pdf]

#72

Post by baxtr »

avazhi wrote: post #69
baxtr wrote: post #58

Earlier quoted context omitted.

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.

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.

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.

Re: Apple Platform Security (Jan 2026) [pdf]

#73

Post by modeless »

philsnow wrote: post #71
modeless wrote: post #64

Earlier quoted context omitted.

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 fo…

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.

Signal and Apple and Google all use HSMs in datacenters as well as on device.

Re: Apple Platform Security (Jan 2026) [pdf]

#74

Post by porcoda »

bigyabai wrote: post #59
baxtr wrote: post #58

Earlier quoted context omitted.

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.

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.

In their revenue report this week out of $140B, services made up 30B. 140B-30B = 110B. Thats pretty far from bankruptcy.

Re: Apple Platform Security (Jan 2026) [pdf]

#75

Post by anon7000 »

avazhi wrote: post #69
baxtr wrote: post #58

Earlier quoted context omitted.

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.

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.

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.

Re: Apple Platform Security (Jan 2026) [pdf]

#76

Post by relium »

rrgok wrote: post #22

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.

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.

Re: Apple Platform Security (Jan 2026) [pdf]

#77

Post by bambax »

OGEnthusiast wrote: post #48
Noaidi wrote: post #33

Earlier quoted context omitted.

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.

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.

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.

Re: Apple Platform Security (Jan 2026) [pdf]

#78

Post by promiseofbeans »

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

Re: Apple Platform Security (Jan 2026) [pdf]

#79

Post by microtonal »

runjake wrote: post #14
modeless wrote: post #12

[flagged]

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…

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.

Re: Apple Platform Security (Jan 2026) [pdf]

#80

Post by vsgherzi »

promiseofbeans wrote: post #78

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,…

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
Post reply on HN