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

31–40 of 205 posts

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

#31

Post by bigyabai »

wcfrobert wrote: post #28

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.

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.

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

#33

Post by Noaidi »

wcfrobert wrote: post #28

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.

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.

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

#34

Post by TheNewsIsHere »

Retr0id wrote: post #25
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.

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.

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.

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

#35

Post by armadyl »

digiown wrote: post #24
drnick1 wrote: post #20

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.

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

> 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.

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

#36

Post by vrosas »

wcfrobert wrote: post #28

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.

[flagged]

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

#37

Post by Retr0id »

TheNewsIsHere wrote: post #34
Retr0id wrote: post #25

Earlier quoted context omitted.

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.

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

These devices still have all the security features.

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

#38

Post by philsnow »

modeless wrote: post #12

[flagged]

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...

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

#39

Post by amelius »

drnick1 wrote: post #20

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.

Yes, how can we verify this? Who says three-letter agencies have no access?

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

#40

Post by surajrmal »

digiown wrote: post #24
drnick1 wrote: post #20

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.

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

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