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

161–170 of 205 posts

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

#161

Post by bossyTeacher »

jmaker wrote: post #129
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.

Can someone explain what the real difference is to a consumer user between an iPhone and a Pixel or a Samsung device? Across all services, push notifications, and device backups. Both promise security, Apple promises some degree of privacy. Google stores your encryption keys, and so does Apple unless you opt in for ADP. Is it similar to Facebook Messenger (encrypted in transit and at rest but Meta can read it) and Te…

> Can someone explain what the real difference is to a consumer user between an iPhone and a Pixel or a Samsung device? Across all services, push notifications, and device backups.

By default, Apple offers you at no charge: email aliases, private relay, Ask No Track barrier. These are just the ones I can think of right now. I am sure there are more. A big thing with Apple is not that they offer different privacy services but they make it EASY and SEAMLESS to use. No other company comes close.

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

#162

Post by pjmlp »

ksec wrote: post #140
pjmlp wrote: post #125

Earlier quoted context omitted.

Yes, that is however a dialect, and one of the goals to Swift Embedded roadmap is to replace it.

So they were not joking when they say they want Swift to replace from Assembly to Javascript. I dont think this will end well.

It has been on Swift and Apple's official documentation since the early days.

People keep forgetting that Objective-C also had a full stack role on NeXTSTEP.

And the same full stack approach was also a thing on Xerox PARC systems, which mostly failed due to mismanagement.

Usually ends well for closed source platform vendors when developers aren't allowed to come up with alternatives like on FOSS operating systems.

At least, as long as the platform stays market relevant.

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

#163

Post by amelius »

daneel_w wrote: post #141
amelius wrote: post #39

Earlier quoted context omitted.

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

We can't verify that the Pixel phones are safe. Nor can the GrapheneOS people, because they don't know everything that's running in the Google Tensor SoC, and they don't have the source code to the firmware running in the Samsung Exynos cellular modem.

Neither can we with Apple phones.

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

#164

Post by baxtr »

porcoda wrote: post #74
bigyabai wrote: post #59

Earlier quoted context omitted.

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.

And that was just one quarter…

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

#165

Post by traceroute66 »

jmaker wrote: post #153
traceroute66 wrote: post #148

Earlier quoted context omitted.

> Apple promises some degree of privacy. Apple also makes it easier to achieve that privacy: - They put all the privacy controls in one place in Settings so you can audit - App developers are mandated to publish what they collect when publishing apps to the App Store.

> - They put all the privacy controls in one place in Settings so you can audit That’s true. On Pixel Android, there’s several unrelated places in the various settings for the device and for the Google account to take care of and see that they do not collide. And for every function there’s always some sort of small print like “it’s all private to you unless you choose to share” - but to use any of the features/servic…

> From what I heard and read, I understood that as a well-meant idea but still a misconception on the consumer part due to lack of enforcement by Apple.

I'm not familiar with the detail so I cannot comment directly on what you are saying. I don't have the time to go read up on it right now.

But what I would say is that many aspects will be indirectly enforced by Apple (and can be audited/enforced by the user) through the privacy controls (location services, microphone, camera etc.). Clearly that does not cover everything, but it covers a large chunk.

Apple have also made it impossible to for example get a device-level ID, you can only get an app-level pseudo-device-id. So there are various code-level enforcements too.

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

#166

Post by isoprophlex »

isoprophlex wrote: post #132
jmaker wrote: post #129

Earlier quoted context omitted.

Can someone explain what the real difference is to a consumer user between an iPhone and a Pixel or a Samsung device? Across all services, push notifications, and device backups. Both promise security, Apple promises some degree of privacy. Google stores your encryption keys, and so does Apple unless you opt in for ADP. Is it similar to Facebook Messenger (encrypted in transit and at rest but Meta can read it) and Te…

Some of these companies don't make money from you, the end user, but by selling ads and data to more effectively deliver said ads. Differences in capabilities, experience and implementation are all downstream from that. In other words, everyone pays lip service to privacy and security, but it's very difficult to believe that parties like Meta or Google are actually being honest with you. The incentives just aren't th…

Addendum: this just in. Apple has much more to lose if they pull something like this; for meta, news like this... barely registers? At least I'm not surprised at all

https://www.theguardian.com/technology/2026/jan/31/us-author...

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

#167

Post by [deleted] »

dan-robertson wrote: post #86
gumby271 wrote: post #65

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

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.

[deleted]

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

#168

Post by fsflover »

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.

Giving all your private data to Apple is not "privacy and security", https://news.ycombinator.com/item?id=39927657

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

#169

Post by fsflover »

amelius wrote: post #163
daneel_w wrote: post #141

Earlier quoted context omitted.

We can't verify that the Pixel phones are safe. Nor can the GrapheneOS people, because they don't know everything that's running in the Google Tensor SoC, and they don't have the source code to the firmware running in the Samsung Exynos cellular modem.

Neither can we with Apple phones.

But we can go to a great length in verifying GNU/Linux phones with available schematics.

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

#170

Post by ksec »

pjmlp wrote: post #162
ksec wrote: post #140

Earlier quoted context omitted.

So they were not joking when they say they want Swift to replace from Assembly to Javascript. I dont think this will end well.

It has been on Swift and Apple's official documentation since the early days. People keep forgetting that Objective-C also had a full stack role on NeXTSTEP. And the same full stack approach was also a thing on Xerox PARC systems, which mostly failed due to mismanagement. Usually ends well for closed source platform vendors when developers aren't allowed to come up with alternatives like on FOSS operating systems. At…

>People keep forgetting that Objective-C also had a full stack role on NeXTSTEP.

In terms of Apps and Low Level Stack Objective-C doesn't seems wrong in my book. The problem is Swift begin as a much larger language and evolve into a gigantic pile of a little of everything.

Post reply on HN