Live data from Hacker News

Apple Photos phones home on iOS 18 and macOS 15

lapcatsoftware.com

501–510 of 1001 posts

Re: Apple Photos phones home on iOS 18 and macOS 15

#501
post #292

What I want is very simple: I want software that doesn't send anything to the Internet without some explicit intent first . All of that work to try to make this feature plausibly private is cool engineering work, and there's absolutely nothing wrong with implementing a feature like this, but it should absolutely be opt-in. Trust in software will continue to erode until software stops treating end users and their data…

> Trust in software will continue to erode > there is an increasing discontent growing towards opt-out telemetry Really? That's news to me. What I observed is people giving up more and more privacy every year (or "delegating" their privacy to tech giants).

One of the reasons is because telemetry and backdoors are invisible. If the phone was showing a message like "sending your data to Cupertino" then users were better aware of this. Sadly I doubt there will be a legal requirement to do this.

Re: Apple Photos phones home on iOS 18 and macOS 15

#502
post #462
post #417

Earlier quoted context omitted.

Absolutely! The important bit is that users have no choice in the matter. They're pushed into agreeing to whatever ToS and updating to whatever software version. The backlash against Microsoft's Windows Recall should serve as a good indicator of just how deeply people have grown to distrust tech companies. But Microsoft can keep turning the screws, and don't you know it, a couple years from now everyone will be runni…

If you accept Android as an option, then GrapheneOS probably check a lot of your boxes on an OS level. GrapheneOS developers sit between you and Google and make sure that shit like this isn't introduced without the user's knowledge. They actively strip out crap that goes against users interests and add features that empower us. I find that the popular apps for basic operation from F-Droid do a very good job of not sc…

As the GP already mentioned, F-Droid (as great as it is) won't help you access your bank account.

Re: Apple Photos phones home on iOS 18 and macOS 15

#503

Earlier quoted context omitted.

> It's the equivalent of sending an MD5 of your password somewhere a) MD5 is reversible, it just cost GPU time to brute force b) It is unproven that their implementation is irreversible

BFV has been proven to be irreversible, and Apple open sourced their Swift library implementing it, so it's not totally unproven. https://github.com/apple/swift-homomorphic-encryption

[deleted]

Re: Apple Photos phones home on iOS 18 and macOS 15

#504
post #11

"I don't understand most of the technical details of Apple's blog post" I do: - Client side vectorization: the photo is processed locally, preparing a non-reversible vector representation before sending (think semantic hash). - Differential privacy: a decent amount of noise is added the the vector before sending it. Enough to make it impossible to reverse lookup the vector. The noise level here is ε = 0.8, which is q…

I appreciate the explanation. However, I think you do not address the main problem, which is that my data is being sent off my device by default and without any (reasonable) notice. Many users may agree to such a feature (as you say, it may be very secure), but to assume that everyone ought to be opted in by default is the issue.

"Your data" is not actually being sent off your device, actually, it is being scrambled into completely unusable form for anyone except you.

This is a much greater level of security than what you would expect from a bank, for example, who needs to fully decrypt the data you send it. When using your banking apps over HTTPS (TLS), you are trusting the CA infrastructure, you are trusting all sorts of things. You have fewer points of failure when a key for homomorphic encryption resides only on your device.

"Opting-in by default" is therefore not unsafe.

Re: Apple Photos phones home on iOS 18 and macOS 15

#505
post #286

Earlier quoted context omitted.

I don't think that's a fair characterization of what they're doing.

No? There’s literal billboards linked on this thread that say “what happens on your iPhone stays on your iPhone.” Apple patting itself on the back.

If you one-way encrypt a value, and that value leaves the phone, with no way to recover the original value, then the original data never left the phone.

Re: Apple Photos phones home on iOS 18 and macOS 15

#506
Apple decided to siphon user photo derived data without prior consent. The purpose, capacity and risk of said data being in others’ hands we are expected to take their word for. All while not informing users in advance or trusting users to themselves decide to start the siphoning. By doing this they have violated some users trust.

Re: Apple Photos phones home on iOS 18 and macOS 15

#507
post #391

Earlier quoted context omitted.

Encryption does not automatically mean secure. Encryptions can and will be broken. Any flaw in their implementation (which nobody can verify) would render encryption useless…

Sure, but it's more than a promise that they won't look. Apple currently believes it's impossible to look.

Apple is not a person, they don’t “believe” anything.

As a corporation, they “calculate” what they can say without getting into more trouble than they’re willing to entertain.

Re: Apple Photos phones home on iOS 18 and macOS 15

#508
post #11

"I don't understand most of the technical details of Apple's blog post" I do: - Client side vectorization: the photo is processed locally, preparing a non-reversible vector representation before sending (think semantic hash). - Differential privacy: a decent amount of noise is added the the vector before sending it. Enough to make it impossible to reverse lookup the vector. The noise level here is ε = 0.8, which is q…

The nearest neighbour search is sharded, which apple's blog admits is a privacy issue, which is why they're running the DP and OHTTP parts.

If apple were to add additional clusters that match "sensitive" content and endeavour to put them in their own shards distinct from landmarks, they defeat the homomorphic encryption part while still technically doing it.

The DP part can be defeated with just statistics over time; someone with any volume of sensitive content will hit these sensitive clusters with a higher likelihood than someone generateing noise injected fake searches.

The OHTTP part can be defeated in several ways, the simplest of which is just having a clause in a non-public contract allowing apple to request logs for some purpose. They're paying them and they can make up the rules as they go.

Re: Apple Photos phones home on iOS 18 and macOS 15

#509
post #427

> I don't understand most of the technical details of Apple's blog post. I did understand the cited bits, and sorry to say but this could have been an optimistic post ("look at this cool new thing!") I dislike Apple's anti-hacker (in the HN sense of the word) practices as much as the next person and don't own any Apple device for that and other reasons, but saying "it doesn't matter how you solved the privacy problem…

Homomorphic encryption is something I heard about through a research paper a few years ago.

Back then I understood that an operation like SUM would be able to compute the sum of a list of numbers where each number was encrypted. The way the encryption worked made it possible to add all the values together without decrypting them, and the result ended up being encrypted too in such a way that the owner could decrypt it and have a number with a certain known accuracy.

If Apple is using homomorphic correctly then there should be no way for them to see the data they get from your phone. The other things they mention in the post as ways to prevent leaking of other information through metadata or a side channel.

The fact that this feature was enabled by default isn’t exactly great. Definitely should have been something that the user should have been asked if they wanted to enable after upgrading.

Re: Apple Photos phones home on iOS 18 and macOS 15

#510
post #315

Earlier quoted context omitted.

> But I think one should also be wary of articles that make you angry and tell you what you suspected all along. (eg see the commenter elsewhere who doesn’t care about the details and is just angry). It’s much easier to spot this kind of rage-bait piece when it is targeting ‘normal people’ rather than the in-group. The article was published by an Apple developer and user, i.e., myself, on my personal blog, which is f…

I’m not interested in telling you what to put on your blog. Do whatever you like. The headline is defensible but, in my opinion, quite sensationalised. People are likely to interpret it as being for an article making much stronger claims than the article actually does. I think a lot of the interactions people had with this submission, especially early on, were because the headline made them mad, rather than because o…

> The headline is defensible but, in my opinion, quite sensationalised.

How would you write the headline?

There's always a criticism of headlines, but headlines are necessarily short. It's like critics want the entire article text to appear in the headline, which is impossible.

I don't know what defensible but sensationalized is supposed to mean.

> I think a lot of the interactions people had with this submission, especially early on, were because the headline made them mad, rather than because of its contents.

That's pure speculation on your part, because the headline is very short and vague. In any case, it's not my fault if people read the headline but not the article. I want people to read the article, not just the headline.

Post reply on HN