Live data from Hacker News

Apple Photos phones home on iOS 18 and macOS 15

lapcatsoftware.com

481–490 of 1001 posts

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

#481
post #457

Earlier quoted context omitted.

“Use a rooted…” Aaaaand no.

So you don't want to actually own your devices?

This line of thinking ignores a whole bunch of legitimate reasons why people knowledgeable enough to root their phone still choose not to, not least of which is that I have to exchange trusting a large corporation with a financial incentive to keep my device secure (regulations, liability) with an Internet anon with incentive to do the opposite (no direct compensation, but access to banking apps on the user’s device).

Even in the case where I’m willing to risk trusting the developer, they have literally zero resources to pen test the software I’ll be running my banking apps on, and in the case of Android roms need to run known vulnerable software (out-of-support source-unavailable binary blobs for proprietary hardware that were never open-sourced).

The same argument was made about TPM’s on PC’s and against Windows 11 for years (that they should just be disabled/sidestepped). It only holds water if you don’t understand the problem the device solves for or have a suitable alternative.

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

#482

Earlier quoted context omitted.

Or just use Linux where no component phones home.

Plenty of Linux distributions phone home, in some way, by default.

They send user data? Source?

Debian has popcon, which must be enabled explicitly and that is it. It sends the list of the installed packages.

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

#483
post #181

Earlier quoted context omitted.

I've read the post you're responding to like 3 times, and after pondering it deeply, I'm pretty sure the conclusion of their line of thinking pretty definitively stops at "Apple should not be sending data off the device without the user requesting it." If you think otherwise, you should maybe provide more of an argument.

Because the conclusion is not workable. Almost every single app today interacts with the network in some way. You would be constantly annoying the user with prompt after prompt if you wanted to get consent for sending any relatively harmless data off the device.

Ah the GDPR complaint. Just don't collect the data and you won't be annoying anyone!

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

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

How would you explain client side vectorization, differential privacy and homomorphic encryption to a layman in a single privacy popup so that they can make an informed choice?

Or is it better to just trust that mathematics works and thus encryption is a viable way to preserve privacy and skip the dialog?

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

#485

Completely, 100% agreed: > the only way to guarantee computing privacy is to not send data off the device. > It ought to be up to the individual user to decide their own tolerance for the risk of privacy violations. [...] By enabling the "feature" without asking, Apple disrespects users and their preferences. I never wanted my iPhone to phone home to Apple. Regardless of how obfuscated or "secure" or otherwise "priva…

> like taking a photo, assuming stuff is sent to this service immediately upon adding a new photo So you jumped to a conclusion based on an incorrect premise. This is easy to see that this does not happen immediately after taking a photo. One the network traffic will show this (and it won’t), two homomorphic encryption is expensive so it cannot. Photos classically doesn’t sync on demand, as most iPhone users will kno…

you're splitting a very fine hair while ignoring the larger privacy implication of the feature. So the timestamp might or might not be delayed a bit from being perfectly accurate? So what? It still is data approximating when the photo was taken, even if the resolution were as bad as "within a few days"

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

#486
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…

How can you trust something you don't understand? That must come from "authority" (some person or org that you trust to know about such matters). That authority isn't Apple for many people. While I have cautious trust in Apple's privacy policies, many people don't, and not without reason. Hence, not understanding Apple's technical explanation of an Apple feature you didn't opt in to sharing personal data, increases the feeling of privacy violation (which in turn leads to more distrust).

So would it be unfair criticism?

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

#488
post #346
post #324

Earlier quoted context omitted.

Developers of software want, and feel entitled to, the data on your computer, both about your usage within the app, as well as things you do outside of the app (such as where you go and what you buy). Software will continue to spy on people so long as it is not technically prohibited or banned.

I don’t. I highly suggest everyone else does their darnedest not too either. Don’t do it in your own software. Refuse and push back against it at $dayJob. I realize that my small contribution as a privacy and data-respecting SWE is extremely small, but if we all push back against the MBAs telling us to do these things, the world will be better off.

Why do you assume it's MBA driven? As a software developer, I like knowing when my software crashes so that I can fix it. I don't care or even want to know who you are, your IP address, or anything that could be linked back to you in any way, but I can't fix it if I don't know that it's crashing in the first place.

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

#489
post #180

Earlier quoted context omitted.

Your answer shows how we all have a very different idea of what our own desired privacy level is. Or what privacy even means.

If you think that sending data to a remote server is equally private to not sending it, then you are the one who doesn't know what privacy means. Of course it's fine to not desire privacy, or to desire a privacy level that is less than private. That's up to you. I liked the privacy of my old Canon digicam that had no internet. A photo app on a phone that sends stuff over the network might bring some useful functional…

Privacy isn't a binary option. There are levels of privacy between "private" and "not private".

What Apple has implemented is a LOT closer to "private" than "not private"

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

#490
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…

This sounds exactly like that CSAM "feature" they wanted to add but created a huge outrage because of how incredibly invasive it was. It sounds like it only needs a few extra lines of code to get exactly what they wanted before, they just packaged it differently and we all fell for it like frogs getting boiled in water.

Oh ffs, not this one again.

The CSAM filtering was a best of class implementation. I'm pretty sure I'm one of maybe a dozen people who actually read the spec before throwing a hissy-fit about "muh privacy!"

The only actual "flaw" was that maybe a state-level actor could make it scan for bad stuff on your device.

BUT they can do it to your cloud data _today_. And if you disabled cloud uploads, the local scanning was disabled too.

Post reply on HN