Comment by amatecha
1 month ago
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 "privacy-protecting" the feature is, the fact is that some information derived from one's personal content is transmitted, without prior consent. Even if the information is protected, all network queries are information. A timestamp that proves you took a certain action at a certain time (like taking a photo, assuming stuff is sent to this service immediately upon adding a new photo), from a certain location (by correlating your location information at that time), etc etc.. and that's just the tip of the iceberg. Transmitting information from a user's device without their explicit consent is a violation of their privacy.
So Signal messages aren't secure because they're transmitted and so their "obfuscation" isn't enough to protect your data? Have you read what the author cited (and then admitted to not understanding) what Apple says they actually do to the data before transmission?
I could see an argument in the metadata (though there are multiple assumptions involved there, not least that they don't truly do OHTTP but instead conspire to learn at what timestamp a user took a picture), but if you already don't trust in what is essentially math, I'm not sure where the uncertainty and doubt ends
The difference being that the signal message is sent with consent: You literally press a button to send it there is a clear causal relationship between clicking the button and the message being sent.
The obvious difference is that by sending your photos with Signal, you are doing it willingly. You let it encrypt and decrypt willingly. You decide who gets it.
Here, Apple does that for you.
Your ISP, a bunch of routers and switches and the servers run by Signal can also see your encrypted photo. You don’t really get to decide who sees the encrypted photo. You do get to decide which photo you encrypt and send though.
3 replies →
> 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 know by way if it telling you this in the photos app when it does sync. Most expensive operations are queued up for when the device is plugged in (and on WiFi) because it’ll otherwise drain battery.
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"
The blog post outlines how Apple goes about disconnecting metadata, so at best they would know that someone took a photo at a rough point in time.
How much size would it take to store a model of every known location in the world and common things?
For ex: I sent a friend a photo of my puppy in the bathtub and her Airpods (via iphone) announced "(name) sent you a photo of a dog in a bathtub". She thought it was really cool and so do I personally. That's a useful feature. IDK how much that requires going off-device though.
> That's a useful feature.
I’m really curious how this feature is considered useful. It’s cool, but can’t you just open the photo to view it?
It is a notification summary.
There is a large number of people out there who receive hundreds of notifications (willingly but mostly unwillingly) daily from apps they have installed (not just messengers), and nearly all of them can't cope with the flood of the notifications. Most give up on tending to the notifications altogether, but some resort to the notification summaries which alleviate the cognitive overload («oh, it is a picture of a dog that I will check out when I get a chance to, and not a pic of significant other who got themselves into a car accident»).
The solution is, of course, to not allow all random apps to spam the user with the notifications, but that is not how laypeople use their phones.
Even the more legit apps (e.g. IG) dump complete garbage upon unsuspecting users throughout the day («we thought you would love this piece of trash because somebody paid us»).
4 replies →
With an assault of notifications while you are busy, being able to determine without lifting your phone whether the alert is something mundane versus what you've been waiting for, is useful. If I'm working outside, removing gloves to check the phone each time it vibrates becomes endlessly disruptive, but I want the phone with me in case family calls, someone's delivering something, there's an urgent work issue, etc.
I’m not an expert, but I would say extremely small.
For comparison Hunyuan video encodes a shit-ton of videos and rudimentary real world physics understanding, at very high quality in only 13B parameters. LLAMA 3.3 encodes a good chunk of all the knowledge available to humanity in only 70B parameters. And this is only considering open source models, the closed source one may be even more efficient.
Maybe we have different understandings of what extremely small is (including that emphasis) but an LLM is not that by definition (the first L). I'm no expert either but the smaller value mentioned is 13e9. If these things are 8-bit integers, that's 13 GB data (more for a normal integer or a float). That's a significant percentage of long term storage on a phone (especially Apple models) let alone that it would fit in RAM on even most desktops which is afaik required for useful speeds. Taking this as upper bound and saying it must be extremely small to encode only landmarks, idk. I'd be impressed if it's down to a few dozen megabytes, but with potentially hundreds of such mildly useful neural nets, it adds up and isn't so small that you'd include it as a no-brainer either
These issues are all addressed in the Apple blog post that talks about how this feature is implemented. Two steps are taken to deal with these risks:
1) iOS creates additional fake queries, and all queries pass through scheduler that ensures you can use time-of-lookup to either discriminate real queries from fake queries, or identify when a photo was taken.
2) All queries are performed anonymously, with the use of a third party relaying service. So there’s no way for Apple to tie a specific query back to a specific device, or even IP address.
Between those two mitigating features. Getting hold of an individuals personal data using this feature requires you to first compromise the targets phone, to disable the fake queries. Then compromise the relaying party to correlate queries back to a specific IP address.
If you can manage all that, then quite frankly you’re a fool for expending all that effort. When you could just use your iOS compromise to have the device send you its location data directly. No need to faff about waiting for your target to take photos, then track multiple landmark lookups, carefully collecting a few bits of additional data per query, until you finally have enough to identify the location of your target or targets.
The whole thing reminds me of XKCD 538.
https://machinelearning.apple.com/research/homomorphic-encry...
Is there a way to verify the claims of obfuscation, security and privacy? Or is the only verifiable fact the sending of unknown data to apple by the photos app?