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 and resources (e.g. network connections) as the vendor's own playground. Local on-device data shouldn't be leaking out of radio interfaces unexpectedly, period. There should be a user intent tied to any feature where local data is sent out to the network.
So why didn't Apple just simply ask for user permission to enable this feature? My cynical opinion is because Apple knows some portion of users would instantly disallow this if prompted, but they feel they know better than those users. I don't like this attitude, and I suspect it is the same reason why there is an increasing discontent growing towards opt-out telemetry, too.
This mindset is how we got those awful cookie banners.
Even more dialogs that most users will blindly tap "Allow" to will not fix the problem.
Society has collectively decided (spiritually) that it is ok signing over data access rights to third parties. Adding friction to this punishes 98% of people in service of the 2% who aren't going to use these services anyway.
Sure, a more educated populous might tip the scales. But it's not reality, and the best UX reflects reality.
Nope, collective indifference to subpar user experiences has gotten us those lousy cookie banners.
Web sites could legally use cookies for non-tracking purposes without cookie banners but considering people have not stopped visiting sites despite the fugly click-through cookie banners makes them a failure.
All it takes is for 50% of the internet users to stop visiting web sites with them, and web site authors will stop tracking users with external cookies.
Everyone knows that sarcasm doesn’t transmit well through text. His phrasing isn’t uncommon for something someone would say out loud with a sarcastic tone of voice
Yeah, this is an insane proposal. I know GP may be imagining a smart populace walking away from Big Evil Facebook and X with heads held high, but the other 99% of sites are also doing the same cookie banner stupidity because it is roughly mandatory due to useless EU law (unless you’re not engaging at all in advertising even as an advertiser). So, no more accessing your bank, power utility, doctor, college, etc. That’ll show those pesky cookie banner people!
“The Internet” to someone boycotting cookie banners would basically just be a few self-hosted blogs.
You do not need to show a banner and ask for consent if every cookie is to make the website work (e.g. for authentication and settings). GDPR didn't create this banner; websites that use useless cookies and phone home to Big Tech are.
- Nearly all commercial websites advertise their site in some way
- Nearly all websites people use day-to-day are commercial
- To run ads in a post-1997 world, you must have a conversion pixel because ads aren't sold by impression, they're sold by clicks and they need to know someone made it to your site
- Therefore, some form of tracking cookies (oooh evil) are required
- Big Tech (Google/Meta/X) controls 99% of the real estate where ads can be run, so... they will know about visitors
Unless browsers simply had a setting by default to only save cookies past one session when users allow it. That would be a wildly more effective and efficient solution than forcing every single random website to implement some byzantine javascript monstrosity which attempts to somehow inhibit other JS it doesn't actually control from dropping cookies -- something that the JS API in a browser doesn't even support.
I work on a product that doesn't even have any ad traffic land on it or want to do any tracking, and setting up a cookie management platform was insane. You have to dive into the docs of every SDK to try to figure out how this particular SDK can be signaled to do the GDPR compliance things.
I’m not a web developer, but it seems to me that the referrer that you get after a click on a link should be sufficient to count clicks vs impressions.
I am happy to learn what I may have been imagining: thanks for that!
The law has turned out to be useless, agreed — or at least, it has driven hard-to-navigate UX that we live through today. The intent could have taken us in a different direction with some care (i.e. mandating a clear, no-dark-pattern opt-out/opt-in ahead-of-time option a la DoNotTrack header that similarly failed): if web clients (browsers) were required to pass visitor's preferences and if the list of shared-with was mandated to be machine readable with an exact format (so browsers would create nice UIs), maybe we'd get somewhere.
That's precisely what https://en.wikipedia.org/wiki/EPrivacy_Regulation was supposed to be! As you can imagine, there are strong incentives to lobby against it, so it's almost a decade late already.
Whoever came up with an idea to attach CSAM scanning provision to it is an evil genius, what an incredible way to make sure it's not going to pass any time soon.
'Do not track' was stupid. 'Cannot Be Tracked' would have worked fine. The difference is that the browser is literally the user's agent, so it should work for the user. It is the thing which identifies you today, and could easily NOT identify you without your permission if that was what was mandated -- and "big bad ad tech" could do nothing about it.
Simply select the sites whose first party cookies you want preserved, triggered only by user actively toggling it on, or prompted for on a user-triggered POST that occurs on a page with a user-filled password field (similar to how popups were killed off, no prompting on a POST done without user interaction). "Do you want to let this site 'ycombinator.com' remember you (stay logged in, etc.)?" [YES] [NO]
Otherwise delete the cookies in X minutes/hours/etc.
Or another way, keep the cookies while a tab is on the site, then once no tabs are visiting it, put them in an 'archive.' Upon visiting the site again, show a prompt "Allow ycombinator.com to recognize you from your previous visit(s)?" <Yes> <No, be anonymous> If yes, restore them, otherwise, delete them.
It is so simple to have browsers be responsible for the user's safety, yet since we left it to politicians to decide, we got all this silliness putting it on the users -- and where the technical implementations are by necessity INSIDE the JS sandbox where it's difficult for users to verify that it's being done correctly.
I read an article that said something along the lines of people aren't prepared to pay for apps, so instead we get app store silo advert supported crap-ware. And if it's not the apps its click bait making fractional gains by being supported by ad networks. That some of, but not all of us recoil from.
> All it takes is for 50% of the internet users to stop visiting web sites with them, and web site authors will stop tracking users with external cookies.
How would the content creators or news sites earn then? Web is built on ads, and ads are built on tracking as untargeted ads pays significantly lower than targeted.
No. A significant number of people care about Privacy which is why 1. Apply was targeting them with Ads and 2. AdBlock did hurt Google's business. Also care is different from go to war (as in install Linux and manually setup a privacy shield + Tor + only transact in Monero). Some people do that out of principal. Many people want the Privacy features but with the ease of use.
I'd bet if you ask people "do you care about privacy?" Close to 100% would say yes.
If you ask "you have to give up privacy to be able to log in to your email automatically. Are you ok with that?" Close to 100% would say yes.
If you ask "we will give you this email service for free but in exchange we get to squeeze every ounce of juice that we can out of it to persuade you to buy things you don't need. Are you ok with that?" Close to 100% would say yes.
It doesn't matter what people say they care about. Their actions say otherwise, if the privacy-friendly option is in any way less convenient.
> This mindset is how we got those awful cookie banners.
The only thing I've found awful is the mindset of the people implementing the banners.
That you feel frustration over that every company has a cookie banner, is exactly the goal. The companies could decide that it isn't worth frustrating the user over something trivial like website analytics, as they could get that without having to show a cookie banner at all.
But no, they want all the data, even though they most likely don't use all of it, and therefore are forced to show the cookie banner.
Then you as a user see that banner, and instead of thinking "What a shitty company that don't even do the minimal work to not having to show me the cookie banner", you end up thinking "What a bad law forcing the company to inform me about what they do with my data". Sounds so backwards, but you're not the first with this sentiment, so the PR departments of the companies seems like they've succeed in re-pointing the blame...
Not really. You can still get metrics and analytics, you just don't include PII in it. There are tons of privacy-respecting platforms/services (both self-hosted and not) you can use, instead of just slapping Google Analytics on the website and having to show the banner.
But even so, I'd argue that since it's a small business, you'd do much better with qualitative data rather than quantitative, since it's a small business it's hard to make choices based on small amount of data. Instead, conduct user experience studies with real people, and you'll get a ton of valuable data.
The non-use of collected data is the most ridiculous part of all this. I work with many companies that collect tons of data and only use a small percentage of it. All they're doing is building a bigger haystack.
This is partially due to the fact that Google Analytics is free and the default for most website/app builders. But, still, it's ridiculous.
In my experience, most people that have semi or full decision-making control over this kind of thing have absolutely no idea if they even need cookie consent banners. They just fall for the marketing speak of every single SAAS product that sells cookie-consent/GDPR stuff and err on the side of caution. No one wants to be the guy that says: "hey, we're only logging X, Y and not Z. And GDPR says we need consent only if we log Z, so therefore we don't need cookie consent." For starters, they need a lawyer to tell them it's "A OK" to do it this way, and secondly it's plain old cheaper and a lot less political capital to just go with the herd on this. The cost of the banner is off-loaded outside of the company and, for the time being, the users don't seem to mind or care.
This is why half the web has cookie-consent banners. No amount of developers who know the details screaming up the ladder will fix this. The emergent behavior put in place by the legal profession and corporate politics favors the SAAS companies that sell GDPR cookie banner products and libraries. Even if they're in the right, there is a greater-than-zero percent chance that if they do the wrong thing they'll go to court or be forced to defend themselves. And even then if it's successful, the lawyers still need to be paid, and the company will look at "that fucking moron Joe from the website department" which caused all their hassles and countless hours of productivity as a result of being a "smart ass".
> have absolutely no idea if they even need cookie consent banners
> This is why half the web has cookie-consent banners
Agree, but we as developers can have an impact in this, especially in smaller companies. I've managed to "bark up the ladder" sufficiently to prevent people from mindlessly adding those popups before, and I'm sure others have too.
But those companies have all been companies where user experience is pretty high up on the priority ladder, so it's been easy cases to make.
People think in terms of what is inconveniencing them directly. Great examples are when consumers yell at low level workers when a company has horrible policies that run back to cost cutting...
or union workers strike against Imaginary Mail Service Corp. because they are being killed on the job, and people (consumers) get angry at the workers because their package wont show up on time (or the railways arent running, etc...) instead of getting mad at the company inflicting that damage on other people...
or when [imaginary country] puts sanctions on [other poorer country] the people of that country blame the government in power instead of the people directly inflicting harm on them.
I'm not sure why this is the case, but we have been conditioned to be resistant to the inconvenience and not the direct cause. Maybe its because the direct cause tends to be a faceless, nameless entity that directly benefits from not being the target of ire.
Do you feel like your comment is responding to mine in good faith and using the strongest plausible interpretation? Because it sure feels like you intentionally "misunderstood" it.
Obviously the intention is not "to not improve user privacy at all" but to give companies and users the agency to make their own choices. Many companies seems to chose "user inconvenience" over "user privacy", and it now makes it clear what companies made that choice. This is the intention of the directive.
I didn't intend to criticize your description of the situation. My intent was to criticize the people who (allegedly) had that goal, because it has become clear that the result of the policy was not to cause user frustration and have that lead to companies improving their privacy practices. Instead, the result of the policy was simply to increase user frustration without improving privacy practies.
Those are the same goals, at least in a capitalistic free market. The theory is that consumers will go towards products which are better (meaning, less obnoxious), and therefore the obnoxious websites will either die off or give up the banners to conform to the market.
Naturally, as you can see, free markets are purely theoretical. In practice, up and leaving a website you're using is almost never easy, and isn't even a choice you can make often.
It’s odd that you think the people implementing the banners want them so they can get more data. They want them because they provide a shield from litigation. I don’t know about you, but in the past year, most of my ads on Facebook are from law firms with headlines like “have you browsed (insert random minor e-commerce site) in the past two years? Your data may have been shared. You may be entitled to compensation.” If I’m a random mom and pop e-commerce site and I do not add a cookie banner, and I use any form of advertising at all, then I am opening myself up to a very expensive lawsuit - and attorneys are actively recruiting randos to serve as plaintiffs despite them never being harmed by “data collection.”
It’s that simple. That’s the situation with CCPA. Not sure the exact form that GDPR penalties take because I’m not European. But it’s not a complicated issue. you have to display some stupid consent thing if you’re going to have the code that you’re required to have in order to buy ads which take people to your website.
Note that plenty of these cookie banner products don’t actually work right, because they’re quite tricky to configure correctly, as they’re attempting to solve a problem within the webpage sandbox that should be solved in the browser settings (and could easily be solved there even today by setting it to discard cookies at close of browser). However, the legal assistants or interns at the law firm pick their victims based on who isn’t showing an obvious consent screen. When they see one, it’s likely that they will move onto the next victim because it’s much easier to prove violation of the law if they didn’t even bother to put up a cookie banner. A cookie banner that doesn’t work correctly is pretty easy to claim as a mistake.
> If I’m a random mom and pop e-commerce site and I do not add a cookie banner, and I use any form of advertising at all, then I am opening myself up to a very expensive lawsuit
Nope, that's not how it works. But your whole comment is a great showcase about how these myths continue to persist, even though the whole internet is out there filled with knowledge you could slurp up at a moments notice.
Your comment would be better if you cited any evidence. Otherwise, I could also point you to a whole internet which is, as I said, full of law firm ads fishing for plaintiffs who have only been 'harmed' in the most strained definition of the word.
'Nothing is essential until you prove it is' - apply to the cookie ombudsman for €1k to make your case for allowance.
You complete a detailed form including giving your company registration and the reason for use of each cookie. You list each company with access.
You pay into escrow €10 per user per company (eg 10 users, sending data to 1200 companies; 120000€) you wish to gather/keep data on, providing that users details and an annual fee.
Any non trivial infringement and you get DNS blocklisted, the escrow money is paid out, CEO of the registered company is fined one years income (max of last 4 years) and legal proceedings are started against the company and its executives.
On application to the cookie ombudsman I can see all companies who legally have access to my data (and via which gateway company), I can withdraw access, they can withdraw service.
I think society has collectively "decided" in the same way they "decided" smoking in a restaurant is great.
There's little to no conscious choice in this. But there is a lot of money in this. Like... a LOT of money. If I were to try to influence society to be okay with it, it would be a no brainer.
So, to me, it's obvious that society has been brainwashed and propagandized to accept it. But doing so generates hundreds of billions if not trillions of dollars. How, exactly, such manipulation is done is unknown to me. Probably meticulously, over the course of decades if not centuries. I know that the concept of privacy during the writing of the constitution was much, much more stringent than it was in the 70s, which is much more stringent than it is today.
I think it's clear that users should be able to have their own agents that make these decisions. If you want an agent that always defers to you and asks about Internet access, great. If you want one that accepts it all great. If you want one that uses some fancy logic, great.
u-Block Origin's annoyances filters take care of the cookie banners, giving the best of both worlds: no banners and a minimal amount of tracking.
(The "I don't care about cookies" extension is similarly effective, but since I'm already running u-block origin, it makes more sense to me to enable it's filter.)
> u-Block Origin's annoyances filters take care of the cookie banners, giving the best of both worlds: no banners and a minimal amount of tracking.
Word of caution though, that might silently break some websites. I've lost count of the times some HTTP request silently failed because you weren't meant to be able to get some part of the website, without first rejecting/accepting the 3rd party cookies.
Usually, disabling uBlock, rejecting/accepting the cookies and then enabling it again solves the problem. But the first time it happened, it kind of caught me by surprise, because why in holy hell would you validate those somehow?!
Users had a global way to signal “do not track me” in their browser. I don’t know why regulators didn’t mandate respecting that instead of cookie consent popups.
Apple IDs could easily have global settings about what you are comfortable with, and then have their apps respect them.
I’m spitballing here but wouldn’t another way to handle it would be to return dummy / null responses by redirecting telemetry calls to something that will do so?
This would have the added benefit of being configurable and work on a bunch of apps instead of just one at a time too
Not really. A mandatory opt-in option at the browser level would be the correct way to do it, but legislation forced instead those cookie banners onto the webpage.
No, legislation (the GDPR) doesn’t say anything about cookie pop ups. It says that private data (or any kind) can only be used with opt in consent, given freely, with no strings attached, with the ability to be withdrawn, that it will be kept secure, deleted when not needed for the original purpose, etc. All very reasonable stuff. Tracking cookies are affected, but the legislation covers all private data (IP, email address, your location, etc)
… And if Browsers agreed on a standard to get and withdraw opt-in consent, it would be compatible with what the legislation requires.
The vast majority (>95%) of users does not understand what those pop-ups say, seems fundamentally incapable of reading them, and either always accepts, always rejects, or always clicks the more visually-appealing button.
Try observing a family member who is not in tech and not in the professional managerial class, and ask them what pop-up they just dismissed and why. It's one of the best lessons in the interactions between tech and privacy you can get.
Well, then >95% of users won't be using $FEATURE. Simple as that. The fact that users for some reason no not consent to $FEATURE the way corporations/shareholders would want them to does not give anyone the right to stop asking for consent in the first place.
When looked at from another angle, opt-in does work.
By adding that extra step forcing users to be aware of (and optionally decline) the vendors collection of personal data, it adds a disincentive for collecting the data in the first place.
In other words, opt-in can be thought of as a way to encourage vendors to change their behaviour. Consumers who don't see an opt-in will eventually know that the vendor isn't collecting their information compared to others and trust the product more.
As much as I hate cookie consent dialogs everywhere, the fact is that it is clearly working. Some companies are going as far as to force users to pay money in order to be able to opt out of data collection. If it wasn't so cumbersome to opt-out, I reckon the numbers for opt-out would be even higher. And if companies weren't so concerned about the small portion of users that opt-out, they wouldn't have invested in finding so many different dark patterns to make it hard.
It is definitely true that most users don't know what they're opting out of, they just understand that they have basically nothing to gain anyway, so why opt-in?
But actually, that's totally fine and working as intended. To be fair to the end user, Apple has done something extremely complicated here, and it's going to be extremely hard for anyone except for an expert to understand it. A privacy-conscious user could make the best call by just opting out of any of these features. An everyday user might simply choose to not opt-in because they don't really care about the feature in the first place: I suspect that's the real reason why many people opt-out in the first place, you don't need to understand privacy risks to know you don't give a shit about the feature anyway.
If you do not want it (and that is >90% of people, who never asked for it, never requested it, but was forced upon them these 'enriched' lies and exposure to corporate greed).
> Try observing a family member who is not in tech
This is everyone, it is universal, I've met many people "in tech" who also click the most "visually appealing" button because they are trying to dismiss everything in their way to get to the action they are trying to complete.
The microcosm that is HN users might not just dismiss things at the 95%+ rate, but that is because we are fed, every day, how our data is being misappropriated ate every level. I think outside of these tiny communities, even people in tech, are just clicking the pretty button and making the dialog go away.
The issue really isn't opt-in itself but how the option is presented.
I agree that a lot of people don't read, or attempt to understand the UI being presented to them in any meaningful manner. It really is frustrating seeing that happen.
But, think about the "colorful" option you briefly mentioned. Dark patterns have promoted this kind of behaviour from popups. The whole interaction pattern has been forever tainted. You need to present it in another way.
Informed consent is sexy. In the Apple ecosystem, we’re literally paying customers. This is ridiculous. This line you parroted is ridiculous. This needs to stop.
Except that, still, to this day, most sexual consent is assumed, not explicit, even in the highest brow circles where most people are pro-explicit-sexual-consent.
The same way, most tech privacy consent is assumed, not explicit. Users dismiss popups because they want to use the app and don't care what you do with the data. Maybe later they will care, but not in the moment...
> Except that, still, to this day, most sexual consent is assumed, not explicit
Did you miss my sarcastic little requote blurb that stated exactly that? Or do you normally rephrase the exact same point with added ad hominem attacks, and somehow frame it as a counterpoint?
> The same way, most tech privacy consent is assumed, not explicit.
And yet, you still have a right to it. In both instances.
Anyways, the "right" you have to explicit sexual consent is not really there. In that, you cannot go to court and say "I said no" and get any meaningful damages or a conviction without other evidence. Similarly, courts treat these popups as essentially unreadable and you cannot go to court and say "They clicked "Allow"" and get away with anything unreasonable.
> So why didn't Apple just simply ask for user permission to enable this feature?
That’s an interesting question. Something to consider, iOS photos has allowed you to search for photos using the address the photo was taken at. To do that requires the Photos app to take the lat/long of a photos location, and do a reverse-geo lookup to get a human understandable address. Something that pretty much always involves querying a global reverse-geo service.
Do you consider this feature to be a violation of your privacy, requiring an opt-in? If not, then how is a reverse-geo lookup service more private than a landmark lookup service?
It's a complete violation if it's a new or changed setting from the default state of the user not having it possible.
Something to consider - location is geo-encoded already into photos and doesn't need this uploaded to Apple servers. Searching can be done locally on device for location.
Apple goes as far as to offer a setting to allow the user to share photos and remove the geocoding from it.
Offering a new feature is opt-in.
Unfortunately, against my better wishes, this only erodes trust and confidence in Apple that if this is happening visibly, what could be happening that is unknown.
> Do you consider this feature to be a violation of your privacy, requiring an opt-in?
I suppose in some sense it is, as it a reverse-geo lookup service, but it's also no where near to the front in the location privacy war.
Cell phone providers basically know your exact position at all times when you have your phone on you, credit card companies know basically everything, cars track driving directly, etc. etc.
I can see why some people would be up in arms but for me this one doesn't feel like missing the forest for the trees, it feels like missing the forest for the leaves.
I very much agree with your position. There are legitimate questions to be asked about this feature being opt-in, although we may find that you implicitly opt-in if you enable Apple Intelligence or similar.
But the argument that this specific feature represents some new beachhead in some great war against privacy strikes me as little more that clickbate hyperbole. If Apple really wanted to track people’s locations, it would be trivial for them to do so, without all this cloak and dagger nonsense people seem to come up with. Equally, is a state entity wanted to track your location (or even track people’s locations at scale), there’s a myriad of trivially easy ways for them to do so, without resorting to forcing Apple to spy on their customers via complex computer vision landmark lookup system.
You’re right. But: Anyone in IT or tech, thinking deeply about the raw facts. They know it always boils down to trust, not technology.
The interesting thing is that Apple has created a cathedral of seemingly objective sexy technical details that feel like security. But since it’s all trust, feelings matter!
So my answer is, if it feels like a privacy violation, it is. Your technical comparison will be more persuasive if you presented it in Computer Modern in a white paper, or if you are an important Substack author or reply guy, or maybe take a cue from the shawarma guy on Valencia Street and do a hunger strike while comparing two ways to get location info.
Nope. It's still taking the user's data away without informing them, and saying trust us we super good encrypted it.
Apple is building a location database, for free, from user's photos and saying it's anonymized.
It's not a service I want, nor one I authorize. Nor are my photos licensed to Apple to get that information from me.
Encryption is only good relative to computational power to break it available to the many, or the few.
Computational power usually seems always available in 10-20-30 years to generally break encryption for the average person, as unimaginably hard it seems in the present. I don't have interest in taking any technical bait from the conversation at hand. Determined groups with resources could find ways..
This results in no security or encryption.
> Apple is building a location database, for free, from user's photos and saying it's anonymized.
Where on earth did you get that from? The photos app is sending an 8bit embedding for its lookup query, how are they going to build a location database from that?
Even if they were sending entire photos, how do you imagine someone builds a location database from that? You still need something to figure out what the image is, and if you already have that, why would you need to build it again?
> Encryption is only good relative to computational power to break it available to the many, or the few.
> Determined groups with resources could find ways.. This results in no security or encryption.
Tell me, do you sell tin foil hats as a side hustle or something? If this is your view on encryption why are you worried about a silly photos app figuring out what landmarks are in your photos. You basically believe that it’s impossible for digital privacy of any variety is effectively impossible, and that you also believe this is a meaningful threat to “normal” people. The only way to meet your criteria for safe privacy is to ensue all forms of digital communication (which would include Hacker News FYI). So either you’re knowingly making disingenuous hyperbolic arguments, you’re a complete hypocrite, or you like to live “dangerously”.
> So my answer is, if it feels like a privacy violation, it is. Your technical comparison will be more persuasive if you presented it in Computer Modern in a white paper, or if you are an important Substack author or reply guy, or maybe take a cue from the shawarma guy on Valencia Street and do a hunger strike while comparing two ways to get location info.
They’re broadly similar services, both provided by the same entity. Either you trust that entity or you don’t. You can’t simultaneously be happy with an older, less private feature, that can’t be disabled. While simultaneously criticising the same entity for creating a new feature (that carries all the same privacy risks) that’s technically more private, and can be completely disabled.
> The interesting thing is that Apple has created a cathedral of seemingly objective sexy technical details that feel like security. But since it’s all trust, feelings matter!
This is utterly irrelevant, you’re basically making my point for me. As above, either you do or do not trust Apple to provide these services. The implementation is kinda irrelevant. I’m simply asking people to be a little more introspective, and take a little more time to consider their position, before they start yelling from the rooftops that this new feature represents some great privacy deception.
And how, pray tell, do geotagged images magically get into your Photos library?
I actually couldn't get Photos address search to work right in my testing before writing my previous comment, even with a geotagged photo that I just took. So I'm not sure whether I have some setting disabled that prevents it.
The only match was via character recognition of a printed form that I had photographed.
To be clear, I meant that it was a nonissue for me, because I don't geotag my photos (except in that one test). Whether it's an issue for other people, I don't know.
One of the problems with iPhone lockdown is that it's a lot more difficult to investigate how things work technically than on the Mac.
The point still stands. That’s how geo-tagged images get in your photos, and the search function still works.
For what it’s worth, I’m surprised that you never save photos to your phone that you didn’t take yourself. Do people not send you interesting pictures? Pictures of yourself?
I don't actually use my phone for much. Taking photos, making phone calls. I'm not the kind of person who lives on their phone. I live on my laptop (which has Location Services disabled entirely).
I don't even use Photos app on Mac anymore. They've ruined it compared to the old iPhoto. I just keep my photos in folders in Finder.
you started out suggesting it wasn't possible and when presented with a common case showing it was not only possible but likely, you moved the goal posts and now say "well, I don't do that." Weak sauce.
I admit that I hadn't considered the possibility of importing outside geotagged photos into your own Photos library, because I don't do that. But I also said already, "To be clear, I meant that it was a nonissue for me, because I don't geotag my photos (except in that one test). Whether it's an issue for other people, I don't know."
I don't personally have a strong feeling for or against this particular feature, since I don't use geotagging at all, so it doesn't affect me. I'm neither endorsing nor condemining it offhand. I'll leave it to other people to argue over whether it's a privacy problem. It could be! I just lack the proper perspective on this specific issue.
Yeah, I have geo-tagged images from people having AirDropped photos to me. Occasionally I've noticed a photo somehow says the city it was taken in, much to my surprise -- only to remember this was actually AirDropped to me from someone who was there with me, or whatever. Maybe even iMessaged and then manually saved, not sure.
Personally I do not believe these popups serve any purpose, because I ultimately cannot (at least in a reasonable way) prove that the website is acting in good faith. Asking me whether the app should phone home doesn't really guarantee me pressing "no" will actually prevent the tracking.
I am continuously surprised at how we convince ourselves privacy at scale will work with a varying amount of yes/no buttons. There are 2 ways to trust software 1. be naive and check whether "privacy first" is written somewhere 2. understand the software you are running, down to the instructions it is able to execute.
The permission popups also lack granularity. When giving access to my contact list, which contacts does it actually access? Can I only give access to contacts name and not phone numbers? Is it for offline or online processing? If online, should we have another popup for internet access? But then, can I filter what kind of internet stuff it does? You go down the rabbit hole and eventually end up with a turing-complete permission system, and if you don't, your "privacy" will have some hole to it.
Even with opt-in a vendor will keep harassing the user until they tap "yes" in an inattentive moment.
And I've been in situations where I noticed a box was checked that I'm sure I didn't check. I want to turn these things off and throw away the key. But of course the vendor will never allow me to. Therefore I use Linux.
It is true that there are not absolutely zero instances of telemetry or "phoning home" in Linux, but Desktop Linux is not a similar experience to Windows or macOS in this regard, and it isn't approaching that point, either. You can tcpdump a clean install of Debian or what-have-you and figure out all of what's going on with network traffic. Making it whisper quiet typically isn't a huge endeavor either, usually just need to disable some noisy local networking features. Try Wiresharking a fresh Windows install, after you've unchecked all of the privacy options and ran some settings through Shutup10 or whatever. There's still so much crap going everywhere. It's hard to even stop Windows from sending the text you type into the start menu back to Microsoft, there's no option, you need to mess with Group Policy and hope they don't change the feature enough to need to change a different policy later to disable it again. macOS is probably still better (haven't checked in a while), but there are still some features that basically can't be disabled that leak information about what you're doing to Apple. For example, you can't stop macOS from phoning home to check OCSP status when launching software: there's no option to disable that.
The reason why this is the case is because while the tech industry is rotten, the Linux desktop isn't really directly owned by a tech industry company. There are a few tech companies that work on Linux desktop things, but most of them only work on it as a compliment to other things they do.
Distributions may even take it upon themselves to "fix" applications that have unwanted features. Debian is infamous for disabling the KeepassXC networking features, like fetching favicons and the browser integration, features a lot of users actually did want.
Are there any tools that enable capturing traffic from outside the OS you’re monitoring, that still allow for process-level monitoring?
Meaning, between the big vendors making the OS, and state-level actors making hardware, I wouldn’t necessarily trust Wireshark on machine A to provide the full picture of traffic from machine A. We might see this already with servers running out-of-band management like iDRAC (which is a perfectly fine, non-malicious use case) but you could imagine the same thing where the NIC firmware is phoning home, completely outside the visibility of the OS.
Of course, it’s not hard to capture traffic externally, but the challenge here would be correlating that external traffic with internal host monitoring data to determine which apps are the culprit.
Curiosity has led me to check on and off if the local traffic monitoring is missing anything that can be seen externally a few times, but so far I've never observed this happening. Though obviously, captures at different layers can still yield some differences.
Still, if you were extra paranoid, it wouldn't be unreasonable or even difficult to check from an external vantage point.
> Are there any tools that enable capturing traffic from outside the OS you’re monitoring, that still allow for process-level monitoring?
Doing both of these things at once would be hard, though. You can't really trust the per-process tagging because that processing has to be done on the machine itself. I think it isn't entirely implausible (at the very least, you could probably devise a scheme to split the traffic for specific apps into different VLANs. For Linux I would try to do this using netns.)
For what it's worth, I use Linux, too, but as far as phones go, stock phones that run Linux suffer from too many reliability and stability issues for me to daily drive them. I actually did try. So, as far as phones go, I'm stuck with the Android/iOS duopoly like anyone else.
> I want software that doesn't send anything to the Internet without some explicit intent first
I want this too, but when even the two most popular base OSes don't adhere to this, I feel like it's an impossible uphill battle to want the software running on those platforms to behave like that.
"Local-first" just isn't in their vocabulary or best-interest, considering the environment they act in today, sadly.
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 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.
So long as a significant portion of companies harvest user data to provide “free” services, no well-meaning business can compete with their paid apps. Not in a real way.
It’s the prisoner’s dilemma, but one vs many instead of one vs one. So long as someone defects, everyone either defects or goes out of business.
It’s the same as with unethical supply chains. A business using slave labour in their supply chain will out-compete all businesses that don’t. So well-meaning business owners can’t really switch to better supply chains as it is the same as just dissolving their business there and then.
Only universal regulation can fix this. If everyone is forced not to defect, we can win the prisoners dilemma. But so long as even 10% of big tech defects and creates this extremely lucrative business of personal data trade that kills every company not participating, we will continue to participate more and more.
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.
And of course you've reported every single crash you've encountered via email or support portal?
Normal people don't email support with crash logs, they just grumble about it to their coworkers and don't help fix the problem. You can't fix a problem you don't know about.
And yet we don't have home inspectors coming into our homes unannounced every week just to make sure everything is ok. Why is it that software engineers feel so entitled to do things that no other profession does?
Because software is digital and different than the physical world and someone like you understands that. It's intellectually dishonest to pretend otherwise. How hard is it to make a copy of your house including all the things inside of it? Can you remove all personally identifying features from your house with a computer program? Analogies have their limitations and don't always lead to rational conclusions. Physicists had to contend with a lot of those after Stephen Hawking wrote his book about black holes with crazy theories that don't make sense if you know the math behind them.
Downloading a torrent isn't the same thing as going to the record store and physically stealing a CD, and regular people can also understand that there's a difference between the invasiveness of a human being entering your house and someone not doing that. So either people can understand torrenting isn't the same as going into a store a physically stealing something and anonymized crash logs aren't the same thing as a home inspector coming into your house, or Napster and torrenters actually owe the millions that the RIAA and MPAA want them to.
I'm not saying that all tracking is unequivocally good, or even okay, some of it is downright bad. But let's not treat people as idiots who can't tell the difference between the digital and physical realm.
Once it is running on a computer you don't own, it is no longer your software.
To put it in the language of someone who mistakenly thinks you can own information: data about crashes on computers that aren't yours simply doesn't belong to you.
It's just a matter of ownership and entitlement. You believe you are entitled to things other people own, that is on their property, because you have provided a service to them that's somehow related.
Outside of specifically silicon valley, that level of entitlement is unheard of. Once you put it in human terms what you're asking for, it sounds absolutely outrageous. Because it is - you and I just exist in a bubble.
This can all be avoided and you can have you cake, too. Run the software on your metal. That's what my company does and it's great in many ways. We have a level of introspection into our application execution that other developers can only dream of. Forget logging, we can just debug it.
The pain of a possible future panopticon dwarfs the "pain" of some software crashing. Considering long-term outcomes does not make you a sociopath - quite the opposite.
In the OP article it seems more like users demand to search their photos by text, and Apple has put in a huge effort to enable that without gaining access to your photos.
This is extracting location based data, not content based data in an image (like searching for all photos with a cup in it).
"Enhanced Visual Search in Photos allows you to search for photos using landmarks or points of interest. Your device privately matches places in your photos to a global index Apple maintains on our servers. "
Years ago I developed for iOS as an employee. In my case, it was the product managers that wanted the data. I saw it as a pattern and I hated it. I made my plans to leave that space.
> So why didn't Apple just simply ask for user permission to enable this feature? My cynical opinion is because Apple knows some portion of users would instantly disallow this if prompted, but they feel they know better than those users. I don't like this attitude, and I suspect it is the same reason why there is an increasing discontent growing towards opt-out telemetry, too.
I'm just not sure why Apple needed to activate this by default, other than not draw attention to it... and doing so that was more important than the user's rights to the privacy they believe they are purchasing on their device.
I don't care what convenience i'm being offered or sold. If the user has decided what they want and the premium they are paying for Apple, it must be respected.
This makes me wonder if there is an app that can monitor all settings in an iPhone both for changes between updates, and also new features being set by default to be enabled that compromise the user's known wishes.
Consent for complex issues is a cop out for addressing privacy concerns. Users will accept or reject these things without any understanding of what they are doing either way. Apple seems to have taken a middle ground where they de-risked the process and made it a default.
This is a “look at me, Apple bad” story that harvests attention. It sets the premise that this is an unknown and undocumented process, then proceeds to explain it from Apple documentation and published papers.
"What I want is very simple: I want software that doesn't send anything to the Internet without some explicit intent first."
It exists. I use such software everyday. For example, I am submitting this comment using a text-only browser that does not auto-load resources.
But this type of smaller, simpler software is not popular.
For example, everyone commenting in this thread is likely using a browser that auto-loads resources to submit their comments. HN is more or less a text-only website and this "feature" is not technically necessary for submitting comments. All so-called "modern" web browsers send requests to the internet without explicit intent first. IN addition to auto-loading resources, these browsers automatically run Javascript which often sends further requests never intended by the web user.
Brand new Apple computers now send packets to the internet as soon as the owner plugs them in for the first time. This may enable tracking and/or data collection. Apple proponents would likely argue "convenience" is the goal. This might be true. But the goal is not the issue. The issue is how much the computer owner is allowed to control the computer they buy. Some owners might prefer that the computer should not automatically send packets to remote Apple servers. Often it is not even possible to disable this behaviour. Computer purchasers never asked for these "convenenience" features. Like the subject of this submission, Apple Photos, these are Apple's decisions. The computer owner is not allowed to make decisions about whether to enable or disable "convenience" features.
As the court acknowledged in its opinion in US v Google, default settings are significant. In this case, it is more than a default setting. It is something the owner cannot change.
>I want software that doesn't send anything to the Internet without some explicit intent first.
I too want exactly that, which got me thinking, that's what firewalls are for! DROP OUTBOUND by default, explicit allow per-app.
On Andoid, iptables-based firewalls require root, which wasn't a good option for me (no twrp support for my device), so after some searching I stumbled upon NetGuard - open source and rootless, implements a firewall using Android's VPN service (you can configure Android to route all traffic through this "VPN" which is actually a local firewall). The downside is you can't use an actual VPN (except with some complicated setup involving work profiles and other apps). I've been using it for a couple of weeks and am very satisfied, I noticed apps phoning home which I did not want to, like a scanning app I had used to scan private documents in the past, perhaps an oversight on my part.
Use a rooted Android phone with AFWall+ installed, with default block rules. Even just LineageOS allows you to set granular network settings per app, though it's not preemptive like AFWall.
Can't run various banking apps and can't run PagerDuty on a rooted device due to Google Play API Integrity Check. The ecosystem is closing in on any options to not send telemetry, and Google is leading the way in the restrictions on Freedom.
> Google is leading the way in the restrictions on Freedom.
They're the ones allowing you to root your phone or flash a custom ROM in the first place, so that's not a fair characterisation. Banks have a vested interest in reducing fraud, and a rooted Android might allow for easier and additional attack vectors into their apps and thus systems.
Not really though. I've been using LineageOS+Magisk for at least 6 years and haven't found an app that worked that stopped working all of a sudden. I'm using all my banking apps and everything else without issue, and have been for a long time. Doesn't seem like the app devs are hellbent on blocking those willing to use Magisk.
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.
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 running Windows 11 anyways.
It's the same for Android. If you really want your Android phone to be truly private, you can root it and flash a custom ROM with microG and an application firewall. Sounds good! And now you've lost access to banking apps, NFC payments, games, and a myriad of other things, because your device no longer passes SafetyNet checks. You can play a cat-and-mouse game with breaking said checks, but the clock is ticking, as remote attestation will remove what remains of your agency as soon as possible. And all of that for a notably worse experience with less features and more problems.
(Sidenote: I think banking apps requiring SafetyNet passing is the dumbest thing on planet earth. You guys know I can just sign into the website with my mobile browser anyways, right? You aren't winning anything here.)
But most users are never going to do that. Most users will boot into their stock ROM, where data is siphoned by default and you have to agree to more data siphoning to use basic features. Every year, users will continue to give up every last bit of agency and privacy so as long as tech companies are allowed to continue to take it.
Opt out is portrayed as a choice when it barely is. Because it is very tiresome to always research what avenues exist and explicitly opt put of them and then constantly having to review that option to make sure it isnt flipped in an update or another switch has appeared that you also need to opt out of.
Maybe you need to set an environment variable. Maybe that variable changes. It is pretty exhausting so I can understand people giving up on it.
Is that really giving up on it though? Or are they contorted to it?
If you do anything on the radio without the users explicit consent you are actively user hostile. Blaming the user for not exercising his/her right because they didn't opt out is weird.
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 screwing with the user either. I'm talking about DAVx⁵, Etar, Fossify Gallery, K-9/Thunderbird, AntennaPod etc. No nonsense software that does what I want and nothing more.
I've been running deGoogled Android devices for over a decade now for private use and I've been given Apple devices from work during all those years. I still find find the iOS devices to be a terrible computing experience. There's a feeling of being reduced to a mere consumer.
GrapheneOS is the best mobile OS I've ever tried. If you get a Pixel device, it's dead simple to install via your desktop web browser[1] and has been zero maintenance. Really!
Running a custom ROM locks you out of almost all decent phone hardware on the market since most have locked bootloaders, and it locks you out of a ton of apps people rely on such as banking and money transfer apps. You must recognise that it's not a practical solution for most people.
I've happily used LineageOS without gapps for years across several OnePlus devices. If I ever need a new phone I check their supported devices list to pick, and the stock ROM on my new device gets overwritten the day it arrives. Currently using a OnePlus 8T. When I move on from this device as my primary someday, I may put postmarketOS on it to extend its usefulness.
> Running a custom ROM locks you out of almost all decent phone hardware on the market since most have locked bootloaders
GrapheneOS only works on Pixel devices. Pixel devices are fine. We have reached a point where just about every mid-tier device is fine, really. I run my devices until they are FUBAR or can't be updated due to EOL. EOL for Android (and GrapheneOS) is ~7 years from the release date now.
> it locks you out of a ton of apps people rely on such as banking and money transfer apps.
These can be installed and isolated using work or user profiles in GrapheneOS. Also as https://news.ycombinator.com/item?id=42538853 points out, a lot of work has been put into making Graphene work with banking apps[1].
> You must recognise that it's not a practical solution for most people.
Of course I do. We can act on two levels. We (as a society) can work for regulation and we (computery people) can take direct action by developing and using software and hardware that works in the user's interest. One does not exclude the other.
You don't need tons of choice, but sufficient availability of a decent enough choice. The google piexel line supported by grapheneos is one.
My budget didn't allow me to buy a brand new one but I could buy a second hand pixel 6a for 200€.
Having said that you can also use an older phone with /e/os or lineageos and avoid apps that tracks you by limiting to android apps without telemetry available on f-droid.
The solution is the general populace becoming more tech literate, much like I became more literate in the yellow pages 20 years ago.
The reality is these are no longer mere tools, they are instruments for conducting life. They are a prerequisite to just about any activity, much like driving in the US.
We expect each and every citizen to have an intimate understanding of driving, including nuances, and an understanding of any and all traffic laws. And we expect them to do it in fractions of a second. Because that is the cost of utilizing those instruments to conduct life.
We can act on two levels. We (as a society) can work for regulation and we (computery people) can take direct action by developing and using software and hardware that works in the user's interest. One does not exclude the other.
That said. You can order a Pixel with GrapheneOS pre-installed and Google Apps and services can be isolated.
> I think banking apps requiring SafetyNet passing is the dumbest thing on planet earth. You guys know I can just sign into the website with my mobile browser anyways, right?
No, you're not. For logging in, you need a mobile app used as an authentication token. Do not pass go, do not collect $200... (The current state of affairs in Czechia, at least; you still _do_ have the option of not using the app _for now_ in most banks, using password + SMS OTP, but you need to pay for each SMS and there is significant pressure to migrate you from it. The option is probably going to be removed completely in future.)
Right now I don't think there's anything like this in the United States, at the very least. That said, virtually every bank here only seems to support SMS 2FA, which is also very frustrating.
fwiw, on Android, you can install a custom certificate and have an app like AdGuard go beyond just DNS filtering, and actually filter traffic down to a request-content level. No root required. (iOS forbids this without jailbreaking though :/)
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.
Anything is possible through lobbying for regulation and policy.
It's the same way that bills come out to crack people's policy.
Only people don't always know they can demand the opposite so it never gets messed with again, and instead get roped into fatigue of reacting to technology bills written by non-technology people.
Apple seems to be the best option here too. They seem to have put in a huge effort to provide features people demand (searching by landmarks in this case) without having to share your private data.
It would have been so much easier for them to just send the whole photo as is to a server and process it remotely like Google does.
Individuals who grew up primarily as consumers of tech, also have consented to a relationship of being consumed, bought, and sold themselves as the product.
Those who grew up primarily as creators with tech, have often experienced the difference.
Whether or not people in general are aware of this issue and care about it, I think it's pretty disingenuous to characterize people as willfully giving up their privacy because they own smartphone. When stuff like this is happening on both iOS and Android, it's not feasible to avoid this without just opting out of having a smartphone entirely, and representing as a binary choice of "choose privacy or choose not to care about privacy" is counterproductive, condescending, and a huge oversimplification.
Maybe not privacy in general but this is about location privacy.
If you have a smartphone in your pocket, then, for better or worse, you're carrying a location tracker chip on your person because that's how they all work. The cell phone company needs to know where to send/get data, if nothing else.
It seems disingenuous to put a tracker chip in your pocket and be up in arms that someone knows your location.
Do you honestly believe people understand what they’re doing?
Nowhere in marketing materials or what passes for documentation on iOS we see an explanation of the risks and what it means for one’s identity to be sold off to data brokers. It’s all “our 950 partners to enhance your experience” bs.
The shorter answer is that it's your data, but it's their service. If you want privacy, you should use your own service.
And for how cheap and trivial syncing photos is, any mandatory or exclusive integration of services between app/platform/device vendors needs to be scrutinized heavily by the FTC.
> Trust in software will continue to erode until software stops treating end users and their data and resources (e.g. network connections) as the vendor's own playground. Local on-device data shouldn't be leaking out of radio interfaces unexpectedly, period. There should be a user intent tied to any feature where local data is sent out to the network.
I find that there is a specific niche group of people who care very much about these things. But the rest of the world doesn't. They don't want to care about all these little settings they're just "Oh cool it knows it's the Eiffel tower". The only people who are becoming distrusting of software are a specific niche group of people and I highly suspect they're going to be mad about something.
> So why didn't Apple just simply ask for user permission to enable this feature?
Because most people don't even care to look at the new features for a software update. And let's be serious that includes most of us here otherwise, this feature would have been obvious. So why create a feature that no one will use? It doesn't make sense. So you enable it for everyone and those who don't want it opt-out.
I want a hardware mic switch. We are an iHouse with one exception and that's a SheildTV that is currently out of order because I want to reset it and haven't found time in, oh..., weeks. Anyway, out of the blue one of the kids asked about Turkish delights and wonders where the name came from. SO and I facepalm then explain. Not an hour later she gets something in her Facebook feed: 15 interesting facts about Turkey.
This is just too much of a coincidence. I know, I know, this "... isn't Apple's fault" blah blah. Bullshit it's not. They can't have it both ways where they say their app store process is great and then they allow this shit.
Browsing the Internet is explicit intent! Some of the stuff enabled by JavaScript definitely tows the line but at the very least that's not really the direct fault of the browser.
When it’s done default on, I default opt out until otherwise.
When it’s done default on, I default opt out.
GeoIP is definitely as you say of figuring out the location of an IP.
With photos, geocoding is embedding the gps location in each photo. Those locations are being sent scrubbed but still metadata to Apple.
The more I think of it I’m not sure if it’s useful to me to give that database to Apple for free. If it was presented as it’s being explained in device maybe I’d say cool, yeah.
Would you mind giving an example of something bad that could happen to somebody as a result of Apple sending this data to itself? Something concrete, where the harm would be realized, for example somebody being hurt physically, emotionally, psychologically, economically, etc
Once upon a time, I worked for a pretty big company (fortune 500ish) and had access to production data. When a colleague didn't show up at work as they were expected, I looked up their location in our tracking database. They were in the wrong country -- but I can't finish this story here.
Needless to say, if an Apple employee wanted to stalk someone (say an abusive partner, creep, whatever), the fact that this stuff phones home means that the employee can deduce where they are located. I've heard stories from the early days of Facebook about employees reading partner's Facebook messages, back before they took that kind of stuff seriously.
People work at these places, and not all people are good.
I doubt Apple employees could deduce location from the uploaded data. Having worked at FB I know that doing something like that would very quickly get you fired post 2016
Easy, consider a parent taking pictures of their kid's genitals to send to their doctor to investigate a medical condition, the pictures getting flagged and reported to the authorities as being child pornography by an automated enforcement algorithm, leading to a 10-month criminal investigation of the parent.
This exact thing happened with Google's algorithm using AI to hunt for CP[1], so it isn't hard to imagine that it could happen with Apple software, too.
and there's absolutely nothing wrong with implementing a feature like this, but it should absolutely be opt-in
This feature is intended to spy on the user. Those kinds of features can't be opt-in. (And yeah, holomorophic "privacy preserving" encryption song-and-dance, I read about that when it came out, etc).
This is an incredibly shallow dismissal that states the opposite of Apple's claim with zero evidence or reasoning and hand-waves away the very real and well-researched field of homomorphic encryption.
Users of my (free, open-source) app seem surprised to learn that we've got zero insight into usage patterns. There are situations where a small amount of anonymous telemetry would be extremely helpful but I'm not going to touch it with a barge-pole.
Opt-in makes the data useless - not just in terms of the huge drop in quantity but because of the fact it introduces a huge bias in the data selected - the people that would opt-in are probably not a good sample of "typical users".
Opt-out - no matter what safeguards or assurances I could provide is unacceptable to a subset of users and they will forcefully communicate this to you.
Don't get me wrong - I understand both the ease at which bad actors abuse telemetry and the ease in which "anonymous data" can prove to be nothing of the kind in a multitude of surprising ways.
But it's hard not to feel a little sad in a "this is why we can't have nice things" kind of way.
I can't remember where I saw this before. However, there was a site that collected analytics data client side in a circular buffer (or something), and there was a menu in the settings to send it back one-time or always, or download it yourself. If you experienced an error, they would pop up in a toast to share the analytics data with them so they could help fix the problem. You could, of course, decline.
That was probably the best system I'd seen, but I can't remember what site it was.
The first time I used a flare with their support agents, it truly felt like magic. It's such a clever way to perform data collection for a specific, imperative need without doing a dragnet of constant use telemetry (as far as I'm aware)
Consent is the key issue binding all. There is complete lack of consent when there is no opt-out and great degradation when the default is opt-out. Trust is the only means to consent.
1) Opt-in, Opt-survey, Opt-out is the only ternary to build trust. Survey is an active validator of trust and assists in low-bandwith communication. Question should be presented to the end user the first time using it or the next time the application starts and this feature was added.
2) Provide the exact analytical information you want to the end user so they can parse it too. The means to self-evaluate allowed information to be shared with providing the reports or views improves trust.
3) Known privilege to trust leads to more consent. Having priority support with features and bugs could be aligned with those that Opt-in. Analytical history / performance may assisting in solving the recent bug that was reporter.
Apple, Microsoft, Google, and all apply ambiguity to their analytical sharing without details, not how they use it and can abuse it. Most don't even provide an Opt-out. I don't trust these organizations but I must engage with them through my life. I don't have to use Facebook or Twitter and don't. I accept the Steam survey.
RFC with an agreed upon analytical standard could be step to solving the latch of analytical information the open source community would benefit from. Both parties consenting to agreed upon communication.
*My Point of View; meta data is still personal data. Without the user the data and the meta data would not existing. Since the end user is the entropy to meta data they own the meta and the data.
Building and growing trust makes the data less worthless to the point of being useful. More people will opt-in when they trust the company / the developer(s). Opt-in without a push, universally trust building in the community, keeps leading to this worthless data.
The only way I see moving forward would be community driven effort to build the trust through said means and or other ideas. This not an easy problem to solve and would take time.
*Even the USA agencies like the CDC and FBI must utilize bias data for the decision making since not all states and organizations self-report.
Would there be a way to do the stats gathering on device, then once every few months send a popup with statistics?
Not sure what bias it adds
Like
"hey, we make this app, and we care about privacy, here is the information we have gathered over your usage for the past month, can we send this to ourselves, so that we can use it to improve the app?"
And then show human readable form of what data was collected.
Just as a reference of existing implementations of this: This is essentially how Valve/Steam collects hardware details from users/clients. Every now and then, a popup appears asking the user if they'd like to participate in the "Hardware Survey", together with all the data that would be submitted if they accept.
The podcast app I use, AntennaPod (far better for me than other apps, available on F-Droid, no affiliation!) just gave me a local-only year in review. I thought it was a great touch, and would be happy to have then shared the data from that with the app's makers.
You'd still have extremely biased data - people who blindly click OK on every pop up are not representative of your typical user; people who get nightmares after hearing the word "telemetry" and will gather the pitchforks if they hear any hint of will always refuse, but depending on your app, might be your typical user (e.g. for self-hosted picture sync and catalogue, who is the target audience - people who don't trust Apple/Google/Amazon/Dropbox to store their images privately)
I do find myself on the “private first” side…but also keep in mind that those who grab for pitchforks in defense of privacy aren’t a representative sample of the typical user either. (A purely statistical statement).
It’s very easy to confuse ‘loud protest from a small minority’ and the majority opinion. If a plurality of users chose to participate in an analytics program when asked and don’t care to protest phone-home activities when they’re discovered, then that’s where the majority opinion likely lies.
> people who blindly click OK on every pop up are not representative of your typical user
You could unbias the data by including the metric determining how long did it took them to click "Ok" and whether they actually reviewed the data before agreeing.
This sort of sounds like the Steam Hardware Survey. They do not collect the data willy-nilly, they ask you every few months if you want to participate in a one-time check.
I have an incentive to see if the Linux desktop share has increased, so I usually run the survey for them to get my data point in. I also suppose the "gamer" crowed likes to show off how powerful their "rig" is, so I would imagine they commonly also run the survey for that reason as well.
> Opt-in makes the data useless - not just in terms of the huge drop in quantity but because of the fact it introduces a huge bias in the data selected - the people that would opt-in are probably not a good sample of "typical users".
Why? I don't think that's obvious. It may also be related to the way the opt-in is presented. In general, I would expect this to be a workable solution. Even if the opt-in group deviates from the "typical user", it's the best data you can get in an honest and ethically sound way. This should certainly be better than no data at all?
For any website/app that presents an opt-in cookie consent banner this is implicitly already the case.
Yes, this is one of the main reasons people mostly build on web. It's very difficult to make desktop software better, and especially Linux users are hostile to patterns that would make improvements possible
Hardly. It just has some issues with regards to what you also pointed out, bias for one. But it still provides valuable insight into usage patterns, systemic issues, and enables tracking effects of developments over time. Correcting the bias is not a bigger task than it is now - I'm sure you already have an idea about feedback to different features according to reviews, user reports, discussions, and so on. Opt-in is the same, just much better.
Maybe the solution lies in radical transparency: explaining exactly how and why telemetry would help, then letting users decide. But even that requires trust...
Is there a Github API for creating issues? I also maintain a free, open-source app and would love to make it easy for a crash to give users a button that opens a Github issues form--allowing users to see what crash data is populated and submit it if they want.
Data collection and telemetry is sadly lemon market type of situation. The most trustworthy developers are precisely the ones who don't collect data from users
This can only ever be opt-in if you want to stay on the legal side of the GDPR (and equivalents in other jurisdictions). You can ask, but the default needs to be "no" if no answer is given.
I provide telemetry data to KDE, because they default to collecting none, and KDE is an open-source and transparent project that I'd like to help if I can. If I used your app, I would be likely to click yes, since it's open-source. Part of the problem I have with projects collecting user data is the dark patterns used or the illegal opt-out mechanism, which will make me decline sending telemetry every time, or even make me ditch it for an alternative. An app that asks:
Can we collect some anonymized data in order to improve the app?
[Yes] [No]
...with equal weight given to both options, is much more likely to have me click Yes if none of the buttons are big and blue whilst the other choice is in a smaller font and "tucked away" underneath the other (or worse, in a corner or hidden behind a sub-menu).
Plus, I would think that SOME data would be better than NO data, even if there's an inherent bias leaning towards privacy-minded/power users.
> This can only ever be opt-in if you want to stay on the legal side of the GDPR
The GDPR only applies to personal data. You can collect things like performance data without opt-in (or even an opt-out option) as long as you are careful to not collect any data that can be used to identify an individual, so no unique device IDs or anything like that. Of course, you should be transparent about what you collect. You also have to be careful about combinations of data points that may be innocuous on their own but can be used to identify a person when combined with other data points.
> 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.
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.
All of those are parts of the network infrastructure. They neither "see" the photo, edit it or need it. They don't even know if it's a photo.
Everybody knows that there is a network infrastructure where your content flows through. You willingly accept that as a connected device user because it is necessary to be connected.
What Apple did is not necessary and users don't know about it.
I agree that this isn’t necessary and that Apple should have asked for consent from the user.
I do want to point out that Apple doesn’t get to see your photo. Homomorphic encryption is really cool in that way. Apple isn’t able to decrypt the photo and the results they produce are also encrypted. That’s the beauty of homomorphic encryption. I can send you an encrypted spreadsheet and you can compute the sum of a column for me. I’m the only one who can see the actual sum since you can only see the encrypted sum.
> 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"
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.
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»).
Most people using the device will never go into the notification settings, if an app on install tells you they need notifications to tell you about your driver arriving…and then sends you marketing notifications on the same channel most people will just accept that.
My IG notifications are disabled in perpetuity precisely for that reason, even if it has come at a cost of not receiving IM arrival notifications from a couple of friends who message me exclusively via IG (another enigma – why, as both have my contact details on proper messaging platforms).
Frankly, hundreds of daily notifications is the reality we can't change, and the question is: why do people choose to succumb to the misery of it rather than availing themselves of the proper implements so readily at their disposal?
My armchair explanation is that people can’t cope with being bored. All those notifications are little bits of dopamine hits each time they arrive. It’s not even FOMO, just waiting for something that may be interesting.
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.
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?
My thoughts exactly: "we've got this crafty image fingerprinting, the CSAM detection use proved too controversial to roll out, but let's get the core flows into something that sounds useful for users, so the code atays alive, improving, & ready for future expansion."
Whether such fingerprinting can reliably be limited to public "landmarks" is an interesting question, dependent on unclear implementation details.
Even if the user-visible search is limited to 'landmarks', does the process pre-create (even if only on-device) fingerprints of many other things as well? If so, it suddenly becomes possible for briefly-active non-persistent malware to instantly find images of interest without the wider access & additional processing it'd otherwise take.
The search feature is useful at times, and while local processing is good enough to find (some of the) photos I've taken that match a search term like "table", it can't currently find a photo from a search term of "specific neighbourhood in my city" or "name of specific mountain I climbed years ago" - so if by processing on their servers allows them to do that then it would be genuinely beneficial.
But not beneficial enough to make up for the loss of privacy, so I've disabled it without finding out how useful or not the functionality is.
Yup, this is their way of injecting the "phone home" element via an innocuous rationale, "location matching". The global index will of course also match against other markers they deem worthy of matching, even if they don't return that to the user.
The server must know what it's matching at some point, to be able to generate a response:
> The server identifies the relevant shard based on the index in the client query and uses HE to compute the embedding similarity in this encrypted space. The encrypted scores and set of corresponding metadata (such as landmark names) for candidate landmarks are then returned to the client.
Even with the server supposedly not knowing the identity of the client, the response could simply include extra metadata like some flag that then triggers an instant send of that photo to Apple's (or law enforcement's) servers unencrypted. Who knows?
The setup for “that wasn’t real homomorphic encryption!” is in, when in 2-4 years it comes out that they were doing this exact thing.
The entire concept of a homomorphic encryption system is a land mine outside of obscure academic discussions. In practice systems marketed to the public as “homomorphic encryption” will result in user data exfil mark my words.
Oh, if that's the case, they really could have explained that better. The language used in Apple's article doesn't explain that the server cannot know the query or result (it implies as such, but doesn't make this clear, nor explain how/why)
I find that description perfectly clear for someone who doesn't already know what homomorphic encryption means:
> One of the key technologies we use to do this is homomorphic encryption (HE), a form of cryptography that enables computation on encrypted data (see Figure 1). HE is designed so that a client device encrypts a query before sending it to a server, and the server operates on the encrypted query and generates an encrypted response, which the client then decrypts. The server does not decrypt the original request or even have access to the decryption key, so HE is designed to keep the client query private throughout the process.
Later:
> HE excels in settings where a client needs to look up information on a server while keeping the lookup computation encrypted.
And there's more perfectly layman-understandable in PIR and PNSS sections, complete with real-life examples and simple diagrams.
One just has to read the goddamn thing, which apparently is an insurmountably tall order these days for content that is more than 250 characters.
I read that. It doesn't actually explain how the server can tell me the Eiffel Tower is in my photo without knowing it's telling me that. It glosses over the mechanism by which it can tell me what's in my photo without the service itself knowing. Yeah, cool, never-decrypted. So how do they match up? An ultra-abstract "A[encrypted] + B[encrypted] = A+B[encrypted]" doesn't tell me anything.
As an aside, your unfounded derision about "RTFA" is unwarranted and unnecessary. That was an unusually-hostile response for like, just talking about things.
The server doesn't tell you (and doesn't know) that it's the eiffel tower. Only when the result comes back to your device, is your device able to identify it as such.
I'll take it as if you don't know what homomorphic encryption means.
caveat: this is not rigorous math, just a rough presentation for one to wrap their head around the keystone principles of it
Say you have a space like natural numbers N and a computation function f: N->R. I'm just using R - as in result - so that it's not confusing below:
Take a n in N, f(n) = r, r in R
That's nice, we compute something, but the "computation place" is going to know both n and r.
Now imagine you have an encryption function g that maps every n in N to another integer. I'll just mark encrypted things with ' e.g the encrypted space is N' for easier trackability, so g: N->N' is encryption and its inverse g': N'->N is decryption.
So take a n in N, g(n) = n' in N', and g'(n') = n back again.
N N'
n --- g ---> n'
n <-- g' --- n'
That's basic encryption.
Now back to making f useful: the idea is to have an encryption scheme that allows performing a certain set of operations on the encrypted space and get an encrypted result that results in an identical result once decrypted. From these operations we can have a f' function so that:
for all n in N, f(n) = g'(f'(g(n)))
Visually:
N N' R' R
n --- f --> n' --- g' --> r' --- f' --> r
The whole point is that cheap f and f' happen locally and intensive g' can happen in untrusted places, because all that is seen is an encrypted input n' and encrypted result r'. Only thing it can see is at best that there's A match but not what THE match is, because that all just looks like random numbers; even the no-match case could very well be encrypted and in that case it doesn't even see that.
That is the principle of "homomorphic encryption", and it carries the intrinsic property of the computation place not knowing a single thing about neither the input or the output.
> It doesn't actually explain how the server can tell me the Eiffel Tower is in my photo without knowing it's telling me that.
So it depends on what you mean by "explain how":
- "homomorphic encryption" is the high level answer, described and provided in the Apple article
- if that is not a sufficiently detailed answer then you gotta roll your sleeves up and dive much deeper: the swift-homomorphic-encryption implementation, the BFV paper, the Wally paper, and the other bits that help prevent accidental side channel leaking are all both superficially discussed in a synthetic way and deep-linked in the Apple article in "would you like to know more" fashion.
Or maybe you wanted to know how they performed the actual match (g') in the encrypted space?
> With PNNS, the client encrypts a vector embedding and sends the resulting ciphertext as a query to the server. The server performs HE computation to conduct a nearest neighbor search and sends the resulting encrypted values back to the requesting device, which decrypts to learn the nearest neighbor to its query embedding
Which is possible because they
> have implemented the Brakerski-Fan-Vercauteren (BFV) HE scheme, which supports homomorphic operations that are well suited for computation (such as dot products or cosine similarity) on embedding vectors that are common to ML workflows.
My apologies for the harsh words, they were not meant as an ad hominem, more like a general ranty reflection on the state of the web society.
>not if you need to access from multiple devices (otherwise, what's the point of this feature?)
I don't think the feature works perfectly fine on single device. You take a ton of pictures on your iPhone. You search your photos for "Eiffel tower" and it shows you the photos you took of the Eiffel tower. I don't see why you need multiple devices.
Honestly, why the hell would Apple bother with such a contrived and machiavellian strategy to spy on their users?
They literally own the code to iOS. If they wanted to covertly track their customers, they could just have their devices phone home with whatever data they wanted to collect. Realistically there would be no way to know if this was actually happening, because modern devices emit so much encrypted data anyway, it wouldn’t be hard to hide some nefarious in all the noise.
Time Cook isn’t some Bond villain, sitting in a giant chair, stroking a white cat, plotting to take over the world by lulling everyone into a false sense of privacy (I mean Zuckerburg already did that). Apple is just a large giant corporation that wants to make money, and is pretty damn open about that fact. They clearly think that they can make more money by doubling down on more privacy, but that doesn’t work if you don’t actually provide the privacy, because ultimately, people are really crap at keeping secrets, especially when a media group would happily pay for a story, even at Apple.
Yeah, that sorta already exists. If you've ever done remote customer support, they can send a query to remotely-view your screen -- a query which you have to accept or deny. There's really zero reason there couldn't be a similar feature, but without asking you, and without putting a big red bar a the top of your screen that says "Apple Support is viewing your screen". Wish I had a screenshot or photo of that, can't seem to find a screenshot online unfortunately.
Yes my thoughts as well. The tech was so expensive I guess that they had a need to test / run it to proof it’s private? I mean the model to find landmarks in your photos could run locally as well or? Ok I’m not 100% sure here.
If this was a feature on its own then it would not be popular.
Citing national security, some danger will justify its existence.
Apple alone does not control and dictate what goes in, once you reach their level of size and wealth that exceed even developed countries, you ultimately cannot be the controller of your destiny purely as a profit orientated corporation.
Very likely yes. Why else would they add a feature that incurs costs for them as an update, at no cost to the users (and not even make a fuss about it)?
It is obvious they are monetizing this feature somehow. Could be as innocuous as them training their AI dataset, or feeding into their growing ad business (locations and other things identified in the photos), or collaboration with law enforcement for various purposes (such as notifying the CCP about people's Winnie-the-Pooh memes), or a lot more ominous things.
> Very likely yes. Why else would they add a feature that incurs costs for them as an update, at no cost to the users (and not even make a fuss about it)?
Erm, you’re aware of the whole Apple intelligence thing right? An entire product that costs Apple money, provided at “no cost” to the user (if you had an iPhone 15). Also every feature in an OS update has a costs associated with it, and iOS updates have cost money for the best part of a decade now.
Has it occurred to you that reason Apple includes new features in their updates is to provide customers with more reasons to buy more iPhones? Just because feature are provided at “no cost” at point of consumption, doesn’t mean Apple won’t make money in the long run, and selling user data isn’t the only way to monetise these features. Companies have been giving out “freebies” for centuries before the internet existed, and the possibility of large scale data collection and trading was even imaginable.
Of course, but those would be features in the product code deployed on users' devices (one time investment), not a service that has ongoing costs of operation associated with each call. They wouldn't just give this out for free (especially to older iPhones), it makes no business sense. If you're not paying for a product, you are the product!
CSAM scanning takes place on the cloud with all the major players. It only has hashes for the worst of the worst stuff out there.
What Apple (and others do) is allow the file to be scanned unencrypted on the server.
What the feature Apple wanted to add was scan the files on the device and flag anything that gets a match.
That file in question would be able to be decrypted on the server and checked by a human. For everything else it was encrypted in a way it cannot be looked at.
If you had icloud disabled it could do nothing.
The intent was to protect data, children and reduce the amount of processing done on the server end to analyse everything.
Everyone lost their mind yet it was clearly laid out in the papers Apple released on it.
Apple sells their products in oppressive regimes which force them to implement region specific features. E.g. China has their own iCloud, presumeably so it can be easily snooped on.
If they were to add this anti-CSAM feature, it is not unreasonable to think that Apple would be forced to add non-CSAM stuff to the database in these countries, e.g. anything against a local dictatorship/ etc. Adding the feature would only catch the low hanging CSAM fruit, at the cost of great privacy and probably human life. If it was going to stop CSAM once and for all, it could possibly be justified, but that's not the case.
"It only has hashes for the worst of the worst stuff out there." [citation needed]
I know someone whose MS account was permabanned because they had photos of their own kid in the bathtub. I mean, I guess the person could have been lying, but I doubt they would even have been talking about it if the truth was less innocuous.
Sure, and they do that because Microsoft's CSAM detection product (which other providers like Google supposedly use) operates by having unencrypted data access to your files in the cloud.
What Apple wanted to do is do those operations using homomorphic encryption and threshold key release so that the data was checked while still encrypted, and only after having a certain number of high likelihood matches would the possibility exist to see the encrypted data.
So the optimistic perspective was that it was a solid win against the current state of the industry (cloud accounts storing information unencrypted so that CSAM products can analyze data), while the pessimistic perspective was that your phone was now acting as a snitch on your behavior (slippery slope etc.)
I'm just refuting what the person I responded to said, because apparently these services have hashes for more than just "the worst of the worst stuff" or whatever.
It works by generating a hash on known materials. Those hashes are shared with other companies so they can find that material without having to see the horrific stuff. The chance of a hash collision was also detailed in the paper which is so low to be non-existent. Even if a clash occurs a human still reviews the materials, and it normally needs a couple of hits to trigger an audit (again according to apples paper on it).
> I know someone whose MS account was permabanned because they had photos of their own kid in the bathtub
So you ask me for a citation and then give me anecdotal evidence?
Even if that happened it has nothing to do with CSAM.
I can't believe how uninformed, angry, and still willing to argue about it people were over this. The whole point was a very reasonable compromise between a legal requirement to scan photos and keeping photos end-to-end encrypted for the user. You can say the scanning requirement is wrong, there's plenty of arguments for that. But Apple went so above and beyond to try to keep photo content private and provide E2E encryption while still trying to follow the spirit of the law. No other big tech company even bothers, and somehow Apple is the outrage target.
There is absolutely no such legal requirement. If there were one it would constitute an unlawful search.
The reason the provider scanning is lawful at all is because the provider has inspected material voluntarily handed over to them, and through their own lawful access to the customer material has independently and without the direction of the government discovered what they believe to be unlawful material.
The cryptographic functionality in Apple's system was not there to protect the user's prviacy, the cryptographic function instead protected apple and their datasources from accountability by concealing the fingerprints that would cause user's private data to be exposed.
A law by the government requiring proactive scanning of photos would in fact make the whole situation worse in the US because there would need to be a warrant if the government is requiring the scan. As long as it's voluntary by the company and not coerced by the government, they can proactively scan.
> What the feature Apple wanted to add was scan the files on the device and flag anything that gets a match.
This is not the revelation you think it is. Critics understood this perfectly.
People simply did not want their devices scanning their content against some opaque uninspectable government-controlled list that might send you to jail in the case of a match.
More generally, people usually want their devices working for their personal interests only, and not some opaque government purpose.
From my understanding, it didn't scan all of the files on the device, just the files that were getting uploaded to Apple's iCloud. It was set up to scan the photos on the device because the files were encrypted before they were sent to the cloud and Apple couldn't access the contents but still wanted to try to make sure that their cloud wasn't storing anything that matched various hashes for bad content.
If you never uploaded those files to the cloud, the scanning wouldn't catch any files that are only local.
Your understanding is correct, as was/is the understanding of people critical of the feature.
People simply don't want their device's default state to be "silently working against you, unless you are hyperaware of everything that needs to be disabled". Attacks on this desire were felt particularly strongly due to Apple having no legal requirement to implement that functionality.
One also can't make the moral argument that the "bad content" list only included CSAM material, as that list was deliberately made opaque. It was a "just trust me bro" situation.
> People simply don't want their device's default state to be "silently working against you
That was the misconception of what was happening though.
Nothing happens on your device. Only when it gets to the cloud. It just puts a flag on the picture in question to have the cloud scan it.
Which is exactly what happens before Apple suggested it and happens now. Except it does it for all your files.
> One also can't make the moral argument that the "bad content" list only included CSAM material, as that list was deliberately made opaque. It was a "just trust me bro" situation.
CSAM database is run by Interpol. What evidence do you have that they are not being honest?
The scanning and matching is performed on your own device, against a copy of the databases which is encrypted to protect apple and their data providers against accountability for its content. The result of that match is itself encrypted, owing to the fact that the database is encrypted. On upload the query is decrypted and if there are above a threshold matches the decryption keys to all your content are revealed to apple.
Your phone is your most trusted agent-- it's a mandatory part of your life that mediates your interactions with friends, family, lovers, the government, your doctors, your lawyers, and your priest. You share with it secrets you would tell no other person. It's always with you, tracking your location and recording your activities. And in many cases its use is practically mandated. I think it's inappropriate for such a device to serve any interest except your own.
While it is true that the original proposal operated only on images that you would upload to icloud many people assumed the functionality would be applied more widely over time. This article seems to have proved that point: Apple is now applying essentially the same scanning technology (this time they claim the databases is of "landmarks") to otherwise entirely local photos.
My message was an informal argument. Apple has proposed and (now) applied the same spyware technology to their desktop/laptop operating system as well. But for most people in the US their phone absolute does occupy that most-trusted niche. For better or worse. The fact that this trust may currently be ill-advised is all the more reason people should demand change that makes it possible.
> If a government wanted to enforce it then none of what Apple suggested mattered.
Perhaps you live in a dicatorship. If so, I'm sorry. In the united states the power of the government is limited by the constitution. The kind of automated surveillance performed nominally 'consensually' via corporations would be unambiguously unlawful for the government to perform.
> People simply did not want their devices scanning their content against some opaque uninspectable government-controlled list that might send you to jail in the case of a match.
Again I feel like many people just didn't read/understand the paper.
As it stands now all your files/videos are scanned on all major Cloud companies.
Even if you get a hit on the database the hash doesn't put you in jail. The illegal materials do and a human reviews that before making a case.
I have posted numerous neuralhash collisions online already[1] and can generate more on demand. The "chance" is 100% because perceptual hashing schemes do not and cannot achieve cryptographic strength.
> Until someone finds a successful collision attack.
Indeed, and within hours of the hash function being made available to me I developed a second preimage attack (strictly stronger than a collision attack)... allowing me to modify images in a visually non-objectionable way to match an arbitrary hash value.
> Until shareholder/growth pressure causes them to replace that human with an AI.
Indeed, but more than that:
The "human" is still a dire privacy loss. Perhaps Apple's review might have protected you from some erroneous reports to law enforcement, but does it protect you from an apple-employed stalker ex? does it protect you from paparazzi? Does it protect you from the double thinking ("do I photograph my kids playing in the sprinklers? do I take a nude photo of my spouse?") due knowing that your private activity is being watched?
One could easily argue that some AI second level review is an "improvement", which is another reason why your assumption that even that backstop would eventually be removed is a reasonable one.
Yes this is better than upload the entire photo. Just like virus scan can be done entirely on device, can flagging be local?. If homeomorphic encryption allows similarity matching, does not seem entirely private. Can people be matched?
They don't work on the CSAM. They are a cloud provider who makes CSAM reports.
The only thing I see that is wrong in what they claimed is this:
> The problem is that you don't know which pictures will be sent to Apple.
Apple said in their paper that they don't send anything that is flagged. When the cloud sync occurs the files that are flagged get reviewed. All other files remain encrypted.
> They don't work on the CSAM. They are a cloud provider who makes CSAM reports.
--- start quote ---
If you sort NCMEC's list of reporting providers by the number of submissions in 2020, then I come in at #40 out of 168. For 2019, I'm #31 out of 148
I repeatedly begged NCMEC for a hash set so I could try to automate detection. Eventually (about a year later) they provided me with about 20,000 MD5 hashes that match known CP. In addition, I had about 3 million SHA1 and MD5 hashes from other law enforcement sources.
--- end quote ---
Somehow this isn't "working with CSAM or CSAM databases", oh well.
> Apple said in their paper that they don't send anything that is flagged.
This is literally addressed in the article you pretend you read.
> 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, I feel it's not private" doesn't make it true. Because most other people don't understand the cited words either, if they read that far down anyway, this seems like unfair criticism
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.
One specific use Apple is making of homomorphic encryption as of iOS 18 (I think) is for spam callers. You get a phone call, your phone sends Apple the encrypted phone number, they run it against their spam caller database, and you get the encrypted spam/not spam response back. They published a bunch of open source code around this functionality a while back.
I imagine Apple might argue that no private information is sent thanks to the use of homomorphic encryption. But Apple’s explanation rings hollow without the user having the ability to verify that this system is working as described.
It's not just users having the ability to verify it but also the users comprehending it in the first place. Sending something somewhere without the recipient being able to do anything they please with that information is highly unintuitive, and I don't see homomorphic encryption becoming popular anytime soon.
In a bit of personal news, in a previous job I once worked on doing something similarly private to user's browsing history, that is, the browsing history is sent to the server without the server being able to capture or store it. I was the tech lead for writing a prototype, but the whole idea was then vetoed by a VP.
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).
> Hence, not understanding Apple's technical explanation of an Apple feature you didn't opt in to sharing personal data
But this is the fundamental issue. The author has no idea if personal data is being shared, they’ve made an assumption based on their lack of understanding. It’s entirely possible that all this service does (and arguably likely), is provide a private way for your phone to query a large database of landmark fingerprints, then locally try and match those fingerprints to your photos.
It doesn’t require send up private data. The phone could perform large geographic queries (the size of countries) for batches of fingerprints to be cached locally for photo matching. The homographic encryption just provides an added layer of privacy, allowing the phone to make those queries in a manner that makes it impossible for Apple to know what regions were queried for.
iOS photos already uses databases to convert a photo location into an address, so you can do basic location based searching. That will involve doing lookups in Apple global address database, do you consider that a violation of people’s privacy?
So you understand your own device’s security?
You have no more reasons to trust the security of the Apple device in your pocket than you do of an Apple device in a datacenter IMHO.
> sorry to say but this could have been an optimistic post
> don't own any Apple device
So you don't have any skin in the game, but you're criticizing someone who does?
My blog post is written from the perspective of an Apple user whose trust has been violated. It's nice that you think—from a safe distance—the technology is neat, and maybe it is, but that's irrelevant to the main issue, which is the lack of user consent.
Hacker News unfortunately does not respond to this logic unless it is a company they are trained to hate. We could run the same story reporting Google and Meta's opt-out abuses, and it would also reach the frontpage with just as many comments. Except those comments would be violent condemnation, not apologetics and hand-wringing over whitepaper quotes.
It's tragic, because computing is in a professedly imperfect place right now. Digital privacy is under fire, many payments see a 30% digital service surcharge that is wholly arbitrary, and revolutionary cross-platform standards are being supplanted with proprietary and non-portable solutions that does not benefit any user.
As an American, I am ashamed that our government's dysfunction extends to consumer protection.
To me it seems like a reasonable feature that was, for the most part, implemented with great consideration for user privacy, though maybe I’m too trusting of the description. I mostly think this article is rage-bait and one should be wary of ‘falling for it’ when it shows up on hacker news in much the same way that one should be wary when rage-bait articles show up in tabloids or on Facebook.
It seems likely to me that concerns like those of the article or some of the comments in this thread are irrelevant to Apple’s bottom line. A concern some customers may actually have is data usage, but I guess it’s likely that the feature is off if in low data mode.
I wonder if this particular sort of issue would be solved by some setting for ‘privacy defaults’ or something where journalists/activists/some corporate IT departments/people who write articles like the OP can choose something to cause OS updates to set settings to values that talk less on the network. Seems hard to make a UI that is understandable. There is already a ‘lockdown mode’ for iOS. I don’t know if it affects this setting.
Literally all Apple needed to do was not have it enabled by default. Sending stuff over the network without asking is why trust in Apple is reduced further and further.
Not enabling something by default is pretty close to not having it at all. Accessibility is a reasonable exception where it makes sense to have the features even though they are off by default.
I mostly think the reaction to this article is overblown because it appeals popular ideas here about big tech. I think one should be wary of Apple’s claims about privacy: the reason is competition with Google and so they want users to be distrustful of the kinds of features that Google are better at implementing (I don’t want to say Apple isn’t trying to do the right thing either – if you look at accessibility, the competition was very bad for a lot of things for a long time and Apple was good despite the lack of commercial pressure). 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.
> 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 followed mainly by other Apple developers and users. My blog comprises my own personal observations, insights, and opinions. If you see any rage, it would be my own personal rage, and not "bait". Bait for what?
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 of its contents. I think if one is interacting with some submission here due to a maddening headline, one should be wary about such interactions being driven by emotion, leading to poor discussion that is not particularly anchored to the topic of the article, rather than being driven by curiosity.
> 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.
I would probably aim for a title like ‘what does the “Enhanced Visual Search” feature do in iOS 18 and MacOS 15?’ Or ‘how much data is sent to Apple for the new “Enhanced Visual Search” in Photos’.
I think the early comments on this submission were because the headline made them mad because they were incurious and not particularly related to the topic of the article making – most could be under any article about Apple Photos. One early comment was about switching to alternatives to Photos and another was, paraphrasing, ‘I’m so angry. I don’t care about homeomorphic encryption or differential privacy’. Others seemed to follow the theme of the latter. After a while a comment attempted an overview of some of the technical details, which I thought was better.
Perhaps a more precise complaint is that many of the early comments didn’t really depend on the contents of the article – they could go under many Apple submissions – and I think it’s more likely for comments like that to be written while incensed.
I don’t think you’re to blame for the comments people choose to leave.
> I would probably aim for a title like ‘what does the “Enhanced Visual Search” feature do in iOS 18 and MacOS 15?’ Or ‘how much data is sent to Apple for the new “Enhanced Visual Search” in Photos’.
In my opinion, these are actually misleading headlines that don't represent the content of the article. In fact, I've never used the Enhanced Visual Search feature, nor do I know exactly how much data is sent to Apple.
My article was never intended as a kind of feature introduction that you might see in the news media. The main point was always about user consent for uploading data to Apple. To be clear, my article is and has always been a complaint. Thus, I think the headline is accurate. I am complaining, and readers should know that.
> another was, paraphrasing, ‘I’m so angry. I don’t care about homeomorphic encryption or differential privacy’.
> many of the early comments didn’t really depend on the contents of the article
The headline of the article didn't mention homeomorphic encryption or differential privacy, so they must have read the contents.
In the comment you are replying to, I’m trying to explain some of the reasons for the world being the way it is. I’m not trying to convince you to be happy about it.
Apple already communicates home by default. They never even fixed the macOS app signature check that they said they would, and yet people still choose to use the OS.
(And to be clear I’m not even bothered by the signature check)
At a certain point you have to figure that they realize it doesn’t matter short of some government entity forcing them to stop. At the very least the protections they put in place (homomorphic encryption, etc) are more than I think most other companies would ever bother doing.
The OP is evidence. My phone had it turned on which I think is evidence. Together this feels like reasonably strong evidence but maybe something even stronger is easy to find. Vaguely related: https://markxu.com/strong-evidence
I think both of you had it turned on from past OS installs - it's bundled under other search metadata, the config isn't new to 18. And "it's on and I don't remember agreeing" is absolutely not evidence. This is super common - nobody remembers what they enabled a year ago.
Think about it this way: for people who turn off any & everything that phones home (aka anyone who is frustrated by this new "feature"), the chances of them having turned on something like that upon install is almost nil.
It’s a reasonable feature, but should nevertheless require opt-in by the user. The opt-ins could certainly be bundled at install/upgrade time to reduce annoyance.
One thing particularly not clear to me is weather ios scan all data in the phone and send it to be part of public index or not.
I see from how the feature works from the UI it seems it's not. If the feature activated by user action does this still constitute as phoning home?
if anyone else had done this then yes probably it's reasonable feature done reasonably. The problem is Apple has spent tens if not hundreds of millions of dollars advertising that they don't do things like this. That stuff stays on your iPhone unlike that other OS run by yucky advertising company. Apple would never siphon your data, because they care and you aren't the product.
Shit like this, reasonable in isolation or not, undermines that story completely. If they are so willing to just outright lie on a massive billboard, what else will they do when profits demand it?
I think I just noticed a similar thing for search that I'm pretty sure was not there before IOS 18.
Going into Settings -> Search there's an option now for "Help Apple Improve Search", enabled by default.
>Help improve Search by allowing Apple to store the searches you enter into Safari(!!), Siri and Spotlight in a way that is not linked to you. Searches include lookups of general knowledge, and requests to do things like play music and get directions.
If it was there before then it was switched on again.
> allowing Apple to store the searches you enter into Safari […] in a way that is not linked to you
From deanonymization work even a decade ago it was clear that your search history will completely unmask you.
I would need lots of details before I believed that their method of storing the data reliably protected my privacy. (But of course that is not what the quote claims.)
This is worse than the OP. What alternative universe is Apple living in where it thinks that defaulting to collecting people’s search histories without consent is OK?
As trivia, on mac os, the photoanalysisd service will run in the background and look through your photos, even if you never open Apple Photos. It can't be disabled unless you disable SIP (system integrity protection) which requires a complicated dance of reboots and warnings. It will reenable if you turn SIP back on.
It seems Apple are very passionate about analysing your photos for some reason, regardless if you yourself are.
I was. First by the md_worker processes that mysteriously started pinning all of my CPU cores after a git clone. Then by the realization that MacOS had built a full-text index of millions of lines of source code (it only took a few hours of my Mac being too hot to touch).
A lot of Apple's defaults are just plain bizarre. Why the hell is Spotlight seeing source code mimetypes and feeding it to the search index?
I have never once, in all of my years owning a Mac, used Spotlight search to find a source file based on it's text contents. By comparison, I have absolutely wasted probably close to an hour of my life cumulatively mashing the down arrow to find a relevant result that wasn't a Cmake file.
For real! When I search for a term the last thing I want is some esoteric plist file but I’ll return dozens of those hits. Is there a way to exclude these I wonder? Limit it to what I have in the default home directory structure lets say and not go into my launch agents.
> Why is this even a question, do people not look at the settings at all?
No, I expect defaults that aren't asinine from a company that bills themselves as a premium experience for software developers. It should be common sense, for the purposes of providing software to both ordinary users and software developers, to omit source files that aren't relevant search results. It's one of the most annoying features on Windows too, you'd hope Apple would see the writing on the wall and just fix it.
Harboring hope was my mistake, though. Sold my Mac in 2018 and haven't felt a desire to daily-drive MacOS since.
CSAM could already be part of some local service theoretically. Privacy ended with a requirement to have an account linked to the device (not just icloud). There is no account needed to use a Linux computer.
No. The analysis in question is fully local, used for indexing photos by categories in the Photos app. It is unrelated to any cloud features and not something shared across users.
They are also not using your personal photos to feed the location database, most likely public sources and/or Apple Maps data. If they are relying on GPS-tagged public photos alone, you could probably mess up a system like this by spoofing GPS location en-masse and posting them online for years, but for what purpose?
All kinds of nonsense runs and phones home throughout the os. The thing that annoyed me the most is trying to create an account will phone home to apple, such as setting up a local smtp/imap server on the local network.
This whole thing is reminding me of the outrage over Apple and Google's privacy preserving 'Exposure Notification System' system from the Covid years. It defies intuition that they can alert you to exposure without also tracking you, but indeed that's what the technology lets you do.
Similarly here, it feels like the author is leaning into a knee jerk reaction about invasion of privacy without really trying to evaluate the effectiveness of the technologies here (client side vectorization, differential privacy, OHTTP relays, and homomorphic encryption).
Though I 100% agree Apple should ask the user for consent first for a feature like this.
Of course it is not the whole technology stack, but it is something at least. If your evaluation leads to potential problems, you can create issues right there on the github project!
If you have the capability to actually skillfully analyze this type of crypto, disassembling the binaries from your device (or at the very least, an ipsw for your device) should be trivial.
After all, you wouldn’t actually be trusting the source code given to you to match what’s running on your device, would you?
Reverse engineering is a separate skillet on its own, on top of the other ones you need to read the source code and good developers aren't necessarily good at that.
> After all, you wouldn’t actually be trusting the source code given to you to match what’s running on your device, would you?
That's why the best practice in the industry follows reproducible builds.
The comment I was replying to was stating that source code was necessary to solve privacy, I just said you’d need to get down to silicon if you’re going that far. Don’t be rude. I’m unemployed right now.
"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 quite good privacy.
- OHTTP relay: it's sent through a 3rd party so Apple never knows your IP address. The contents are encrypted so the 3rd party never doesn't learn anything either (some risk of exposing "IP X is an apple photos user", but nothing about the content of the library).
- Homomorphic encryption: The lookup work is performed on server with encrypted data. Apple can't decrypt the vector contents, or response contents. Only the client can decrypt the result of the lookup.
This is what a good privacy story looks like. Multiple levels of privacy security, when any one of the latter 3 should be enough alone to protect privacy.
"It ought to be up to the individual user to decide their own tolerance for the risk of privacy violations." -> The author themselves looks to be an Apple security researcher, and are saying they can't make an informed choice here.
I'm not sure what the right call is here. But the conclusion "Thus, the only way to guarantee computing privacy is to not send data off the device." isn't true. There are other tools to provide privacy (DP, homomorphic encryption), while also using services. They are immensely complicated, and user's can't realistically evaluate risk. But if you want features that require larger-than-disk datasets, or frequently changing content, you need tools like this.
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.
I'm not sure I agree -- asking users about every single minor feature is (a) incredibly annoying, and (b) quickly causes request-blindness in even reasonably security-conscious users. So restraining the nagging for only risky or particularly invasive things makes sense to me.
Maybe they should lump its default state into something that already exists? E.g. assume that if you already have location access enabled for Photos (it does ask!), you've already indicated that you're okay with something about this identifying being sent to Apple whenever you take a picture.
My understanding is that Location Services will, among other things, send a hash of local WiFi network SSIDs and signal strengths to a database Apple maintains, and use that to triangulate a possible position for you. This seems loosely analogous to what's going on here with the compute-a-vector thing.
What's the Venn diagram of people who both (1) deliberately refrain from enabling iCloud Photos but nonetheless (2) want the Photos app to phone home to Apple in order to identify landmarks in locally stored photos?
It's probably a pretty large set of people, perhaps even the majority, since I'd suspect that most people don't pay for additional iCloud storage and can't fit their photo library into 5GB.
In fact, I'm willing to bet that if they'd added this feature and gated it behind iCloud Photos being enabled, we'd have different articles complaining about Apple making a cash grab by trying to get people to pay for premium storage. :P
> It's probably a pretty large set of people, perhaps even the majority
As the article notes, this new feature is so "popular" that neither Apple nor the Apple media have bothered to mention it. AFAICT it's not even in Apple's document listing all the new features of iOS 18: https://www.apple.com/ios/ios-18/pdf/iOS_18_All_New_Features...
True, but I don't see how that relates to anything? You asked for a hypothetical set of people who'd have iCloud Photos disabled but would accept metadata being sent to Apple for better search. I can't help you if you want to move the goalposts after I give you that.
Well, neither of us have any way of surveying the public about that, do we? My claim that those people would be okay with it has as much weight as yours that they wouldn't.
I can try to turn down my natural inclination towards cautious phrasing, if you'd like? Get us on the same level. :D
> It's probably a pretty large set of people, perhaps even the majority, since I'd suspect that most people don't pay for additional iCloud storage and can't fit their photo library into 5GB.
Large set? Yes. Majority? No. CIRP says 2/3 of US Apple users pay for iCloud storage[0]. It's this popular for the exact reason you mentioned. Almost no one can fit their photo library into 5GB so they opt in to the cheap 50GB for $0.99/month. 50GB is enough for a lot of people.
Time Machine does not backup your desktop and other spots that might be essential in case of needing a backup. iCloud does.
I know users who would prefer not to trust Apple for anything, and only pay for and use iCloud to backup the Desktop [and similar locations]. If they were to hear that their opt-in for iCloud means that Apple starts copying random things, they would not be happy.
[OT, I use Arq. But admit that iCloud is simpler, and it is not apples to apples.]
IMO, the fact that Apple backs up your keychain to the Mothership; and that this is a "default" behavior that will re-enable itself when shut off, reflects an attitude that makes me very distrustful of Apple.
Huh, I'm honestly kind of surprised. Good to learn something!
Well, I'll take back what I said about the majority. I do still think that the remaining 1/3 of users who don't have enough storage to turn on iCloud Photos qualify as what lapcat was asking for, though.
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.
I'm sure you know that the point of that billboard is to state that your iPhone protects your privacy. That is generally true, Apple is by far the most privacy-focused major phone and software company. Advertising isn't literal, if we're going to be pedantic here the photons emitted by your iPhone's screen technically leave your iPhone and definitely contain private information.
Especially for a company which heavily markets about how privacy-focused it is,
1)sending my personal data to them in any way is not a "feature." It's especially not a feature because what it sets out to do is rather unnecessary because every photo has geotagging, time-based grouping, and AI/ML/whatever on-device keyword assignments and OCR. I can open up my phone right now and search for every picture that has grass in it. I can search for "washington" and if I took a picture of a statue of george washington that shows the plaque, my iPhone already OCR'd that and will show the photo.
2)"minor" is not how I would ever describe sending data based off my photos to them, regardless of how much it's been stuffed through a mathematical meat grinder.
3)Apple is usually very upfront about this sort of thing, and also loves to mention the most minor, insignificant, who-gives-a-fuck feature addition in the changenotes for "point" system updates. We're talking things like "Numbers now supports setting font size in chart legends" (I'm making that up but you get the point.)
This was very clearly an "ask for forgiveness because the data we want is absolutely priceless and we'll get lots of it by the time people notice / word gets out." It's along the lines of Niantic using the massive trove of photos from the pokemon games to create 3d maps of everywhere.
I specifically use iOS because I value my privacy (and don't want my cell phone data plan, battery power, etc to be a data collection device for Google.) Sending data based off my photos is a hard, do-not-pass-go-fuck-off-and-die line in the sand for me.
It's especially shitty because they've gated a huge amount of their AI shit behind owning the current iPhone model....but apparently my several generation old iPhone is more than good enough to do some AI analysis on all my photos, to upload data for them?
> This was very clearly an "ask for forgiveness because the data we want is absolutely priceless and we'll get lots of it by the time people notice / word gets out.
It's very clearly not, since they've gone to huge lengths to make sure they can't actually see the data themselves see the grandparent post.
> It's especially shitty because they've gated a huge amount of their AI shit behind owning the current iPhone model....but apparently my several generation old iPhone is more than good enough to do some AI analysis on all my photos
Hear hear. As if they can do this but not Visual Intelligence, which is just sending a photo to their servers for analysis. Apple has always had artificial limitations but they've been getting more egregious of late.
I think it does address the main problem. What he is saying is that multiple layers of security is used to ensure (mathematically and theoretically proved) that there is no risk in sending the data, because it is encrypted and sent is such a way that apple or any third party will never be able to read/access it (again, based on theoretically provable math) . If there is no risk there is no harm, and then there is a different need for ‘by default’, opt in/out, notifications etc.
The problem with this feature is that we cannot verify that Apple’s implementation of the math is correct and without security flaws. Everyone knows there is security flaws in all software, and this implementation is not open (I.e. we cannot review the code, and even if we could review code we cannot verify that the provided code was the code used in the iOS build). So, we have to trust Apple did not make any mistakes in their implementation.
If you don’t trust Apple to do what they say they do, you should throw your phone in the bin because it has total control here and could still be sending your data even if you opt out.
As someone with a background in mathematics I appreciate your point about cryptography. That said, there is no guarantee that any particular implementation of a secure theoretical algorithm is actually secure.
> There is also no guarantee that Apple isn't lying about everything.
And at that point all the opt-in dialogs in the world don't matter and you should not be running iOS but building some custom Android ROM from scratch.
Agreed, but surely you see a difference between an open source implementation that is out for audit by anyone, and a closed source implementation that is kept under lock & key? They could both be compromised intentionally or unintentionally, but IMHO one shows a lot more good faith than the other.
No. That’s your bias as a nerd. There are countless well-publicised examples of ‘many eyeballs’ not being remotely as effective as nerds make it out to be.
You say this as if being shamed into patching the occasional vuln is equivalent to security best practices.
Open code which can be independently audited is only a baseline for trustworthy code. A baseline none of those three meet. And one which by itself is insufficient to counter a reflections on trusting trust style attack. For that you need open code, diverse open build toolchains, and reproducible builds. None of which is being done by those three.
Are you getting your ideas about security from the marketing department?
Go ahead and put that cup of kool-aid down for a minute. There are so so many OSS packages out there that have never been audited? Why not? Because people have better things to do. How many packages have you audited? Personally, I don't have the skillz to do that. The people that do expect to be compensated for their efforts. That's why so many OSS packges have vulns that go unnoticed until after they are exploited, which is the same thing as closed source.
OSS is not the panacea that everyone touts it to be.
> There are so so many OSS packages out there that have never been audited? Why not? Because people have better things to do.
I'm not aware of any major open source projects that haven't experienced some level of auditing. Coverity alone scans everything you're likely to find in a distribution like Debian or Fedora: https://scan.coverity.com/o/oss_success_stories
> How many packages have you audited?
Several on which I depend. And I'm just one pair of eyeballs.
> Personally, I don't have the skillz to do that.
Then why are you commenting about it?
> OSS is not the panacea that everyone touts it to be.
I don't know who's touting it as a panacea, seems like a strawman you've erected. It's a necessary pre-requisite without which best practices aren't possible or verifiable.
Hypothetical scenario: Theo de Raadt and Bruce Schneier are hired to bring Apple products up to their security standards. They are given a public blog, and they are not required to sign an NDA. They fix every last vulnerability in the architecture. Vladimir Putin can buy MacBooks for himself and his generals in Moscow, enable Advanced Data Protection, and collaborate on war plans in total confidence.
Theo de Raadt is less competent than Apple's security team (and its external researchers). The main thing OpenBSD is known for among security people is adding random mitigations that don't do anything because they thought them up without talking to anyone in the industry.
I am pretty sure that if we had those people in charge of stuff like this there would be no bar above which "opt in by default" would happen, so I am unsure of your point?
Except for the fact (?) that quantum computers will break this encryption so if you wanted to you could horde the data and just wait a few years and then decrypt?
>Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that, on the Internet, nobody should know you’re a dog. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless. Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails.
Quantum computers don't and won't meaningfully exist for a while, and once they do exist, they still won't be able to crack it. Quantum computers aren't this magical "the end is nigh" gotcha to everything and unless you're that deep into the subject, the bigger question you've got to ask yourself is why is a magic future technology so important to you that you just had to post your comment?
Anyway, back to the subject at hand; here's Apple on that subject:
> We use BFV parameters that achieve post-quantum 128-bit security, meaning they provide strong security against both classical and potential future quantum attacks
I’m a cryptographer and I just learned about this feature today while I’m on a holiday vacation with my family. I would have loved the chance to read about the architecture, think hard about how much leakage there is in this scheme, but I only learned about it in time to see that it had already been activated on my device. Coincidentally on a vacation where I’ve just taken about 400 photos of recognizable locations.
This is not how you launch a privacy-preserving product if your intentions are good, this is how you slip something under the radar while everyone is distracted.
In engineering we distinguish the "how" of verification from the "why" of validation; it looks like much comments disagreement in this post is about the premise of whether ANY outgoing data counts as a privacy consent issue. It's not a technical issue, it's a premises disagreement issue and that can be hard to explain to the other side.
The premise of my disagreement is that privacy-preserving schemes should get some outside validation by experts before being turned on as a default. Those experts don’t have to be me, there are plenty of people I trust to check Apple’s work. But as far as I can tell, most of the expert community is learning about this the same way that everyone else is. I just think that’s a bad way to approach a deployment like this.
To play Apple's advocate, this system will probably never be perfect, and stand up to full scrutinity from everyone on the planet. And they also need the most people possible activated as it's an adverserial feature.
The choice probably looks to them like:
A - play the game, give everyone a heads up, respond to all feedback, and never ship the feature
B - YOLO it, weather the storm, have people forget about it after the holiday, and go on with their life.
Wether B works is up to debate, but that was probably their only chance to have it ship from their POV.
Yes. That also was a thoroughly botched version of A, but I think even a good version of A won't see them ship anything within this century.
IMO giving up on having it widely used and just ship it turned off would be the best choice. But it's so obvious, there must be other ceitical reasons (good or bad) that's not an option.
I think I'm saying: you're not sending "your data" off device. You are sending a homomorphically encrypted locally differentially private vector (through an anonymous proxy). No consumer can really understand what that means, what the risks are, and how it would compare to the risk of sending someone like Facebook/Google raw data.
I'm asking: what does an opt in for that really look like? You're not going to be able to give the user enough info to make an educated decision. There's ton of risk of "privacy washing" ("we use DP" but at very poor epsilon, or "we use E2E encryption" with side channel data gathering).
There's no easy answer. "ask the user", when the question requires a phd level understanding of stats to evaluate the risk isn't a great answer. But I don't have another one.
In response your second question, opt in would look exactly like this: don't have the box checked by default, with an option to enable it: "use this to improve local search, we will create an encrypted index of your data to send securely to our servers, etc..." A PhD is not necessary to understand the distinction between storing data locally on a machine vs. on the internet.
Even here with HN crowd: it's not an index, it's not stored on a server, and it's not typical send-securely encryption (not PK or symmetric "encrypted in transit", but homomorphic "encrypted processing"). Users will think that's all gibberish (ask a user if they want to send an index or vector representation? no clue).
Sure, you can ask users "do you want to use this". But why do we ask that? Historically it's user consent (knowingly opting in), and legal requirements around privacy. We don't have that pop up on any random new feature, it's gated to ones with some risk. There are questions to ask: does this technical method have any privacy risk? Can the user make informed consent? Again: I'm not pitching we ditch opt-in (I really don't have a fix in mind), but I feel like we're defaulting too quickly to "old tools for new problems". The old way is services=collection=consent. These are new privacy technologies which use a service, but the privacy is applied locally before leaving your device, and you don't need to trust the service (if you trust the DP/HE research).
End of the day: I'd really like to see more systems like this. I think there were technically flawed statements in the original blog article under discussion. I think new design methods might be needed when new technologies come into play. I don't have any magic answers.
The third choice, after opt-in and opt-out is to force the user to choose on upgrade before they can use their device again. "Can we use an encrypted, low-resolution copy of your photos that even we ourselves can't see?"
Okay except "encrypted, low-resolution copy of your photos" is an incredibly bad explanation of how this feature works. If nobody on HN so far has managed to find an explanation that is both accurate and understandable to the average consumer, any "hey can we do this" prompt for this feature is essentially useless anyways. And, IMO, unnecessary since it is theoretically 100% cryptographically secure.
I think it's sufficiently accurate, why don't you think it is? I don't think the vector vs low-res aspect is particularly material to understanding the key fact that "even we ourselves can't see?"
Exactly. It's the height of arrogance to insist that normal users just can't understand such complex words and math, and therefore the company should not have to obtain consent from the user. As a normal lay user, I don't want anything to leave my device or computer without my consent. Period. That includes personal information, user data, metadata, private vectors, homomorphic this or locally differential that. I don't care how private Poindexter assures me it is. Ask. For. Consent.
Don't do things without my consent!!! How hard is it for Silicon Valley to understand this very simple concept?
Every TCP session leaks some PRNG state for the ISN. That might leak information about key material.
Every NTP session leaks time desync information, which reveals—on modern hardware—relativistic travel, including long airplane trips.
Every software update leaks a fortune about what you run and when you connect.
I don’t think it’s reasonable to ask that people consent to these; I don’t think they can. I absolutely agree that photo metadata is different and at a way higher level of the stack.
> The average smartphone is probably doing a hundred things you didn’t knowingly consent to every second.
You've succinctly identified a (maybe the) huge problem in the computing world today. Computers should not do anything without the user's command/consent. This seems like a hopeless and unachievable ideal only because of how far we've already strayed from the light.
Even Linux, supposedly the last bastion of user control... it's a mess. Do a fresh install and type ps ax at a shell. You'll see dozens of processes in the background doing god knows what. I didn't consent to any of this! The distribution's maintainer simply decided on my behalf that I want the computer to be running all these processes. This is totally normalized!
I don't expect my computer to ask for consent again and again for every byte sent over the network, but I do expect it to obtain my consent before generally accessing the network and sending bytes over the network.
> I do expect it to obtain my consent before generally accessing the network and sending bytes over the network.
How would that make any difference in this case? Presumably, you'll have long-ago checked the "allow general access to the network" setting, so you've given consent to the "send my photo data" action. Heck, surely connecting to the internet in the first place is implicit consent that you want to send stuff over the network?
If I were actually given the choice, I would not check any checkbox allowing an application broad, unfettered access to the network. But, in most cases I'm not even given that choice!
Yes you did. You purchased a computer, put this software on it and executed it. If you didn't want it to do whatever it's doing you should have determined what it would do beforehand and chose not to do it.
Even assuming that running the software implies my consent (which I would dispute), how do I make the decision about whether I should execute the software if I don't know what it is doing?
This all-or-nothing approach is also problematic. I should not have to allow the developer free rein to do whatever he wants, as a condition of using the software. This is why operating systems are slowly building granular permissions and consent checks.
Installing and booting Linux absolutely implies consent to let it do what it does. It's open source, you can evaluate what it does before booting it. You know it's comprised of many processes, you know it has a networking stack, you connected it to a network. You can't then ask OMG why didn't it ask before sending something?
I agree that all-or-nothing is problematic but even with a flexible permission system the best you can hope for is for all the things apps do to be itemized and set to sane defaults. But even then sanity is subjective. For every person like you (and me fwiw) who values privacy there are 1000 people who will never find the settings, don't care about privacy, and will wonder why stuff isn't working.
Ultimately privacy is similar to security in that it comes down to trust. If you don't trust your OS you're screwed. Your choices are try to exert as much control over it as possible, or don't use it.
It’s amazing how hostile Silicon Valley (and HN commenters) are to the basic idea of consent. It’s as if simply asking the user for permission is a grave insult to these technologists. “I shouldn’t have to ask permission! It implies I’m doing something bad!” they might be thinking.
If the world was a nightclub, “Silicon Valley” would be a creepy guy who walks up to every woman and says “You’re now dating me. To stop, you need to opt out using a form that I will do my best to make sure you can’t read.”
You're inverting morality and infantilising the consumer. Apple is a corporation. Corporations don't owe you moral anything, except as required by law.
Choosing an Apple product is consent to trusting Apple. Continued use their products represents ongoing consent. This is an objective fact about all complex connected devices and it cannot possibly be otherwise.
Corporation are driven by people. They’re not a separate entity that decides to do things while their owners are sleeping. Every actions have someone that suggested it and someone that gave the green light.
There is significant middle ground between "do it without asking" and "ask about every single thing". A reasonable option would be "ask if the device can send anonymized data to Apple to enable such and such features". This setting can apply to this specific case, as well as other similar cases for other apps.
If you can't meaningfully explain what you're doing then you can't obtain informed consent. If you can't obtain informed consent then that's not a sign to go ahead anyway, it's a sign that you shouldn't do it.
I mostly agree. I'm just annoyed "this new privacy tech is too hard to explain" leads to "you shouldn't do it". This new privacy tech is a huge net positive for users.
Also: from other comments sounds like it might have been opt-in the whole time. Someone said a fresh install has it off.
> This new privacy tech is a huge net positive for users.
It's a positive compared to doing the same "feature" without the privacy tech. It's not necessarily a positive compared to not forcing the "feature" on the user at all.
The privacy tech isn't necessarily a positive as a whole if it leads companies to take more liberties in the name of "hey you don't need to be able to turn it off because we have this magical privacy tech (that nobody understands and may or may not actually work please don't look into it too hard)".
I don't care if all they collect is the bottom right pixel of the image and blur it up before sending it, the sending part is the problem. I don't want anything sent from MY device without my consent, whether it's plaintext or quantum proof.
You're presenting it as if you have to explain elliptic curve cryptography in order to toggle a "show password" dialogue but that's disingenuous framing, all you have to say is "Allow Apple to process your images", simple as that. Otherwise you can argue many things can't possibly be made into options. Should location data always be sent, because satellites are complicated and hard to explain? Should we let them choose whether they can turn wifi on or off, because you have to explain IEEE 802.11 to them?
> I don't want anything sent from MY device without my consent
Then don’t run someone else’s software on your device. It’s not your software, you are merely a licensee. Don’t delude yourself that you are morally entitled to absolute control over it.
The only way to have absolute control over software is with an RMS style obsession with Free software.
They might not be legally entitled to it, but that's just because of our shitty "intellectual property" laws. Morally speaking, OP is absolutely entitled to have a device that they own not spying on them.
Regardless of one's opinion of intellectual property laws, nobody is morally entitled to demand that someone else build the exact oroduct they want. In fact it is immoral to demand that of other people — and you certainly wouldn’t like it if other people could demand that of you.
Want a phone that doesn’t spy on you? Make it yourself. If you can’t, find some like-minded people and incentivise them (with money or otherwise) to make it for you. If they can’t (or won’t) perhaps contemplate the possibility that large capitalist enterprises might be the only practical way to develop some products.
This has absolutely nothing to do with "might makes right". If a fast food store decides to offer a Vietnamese Peanut Burger and Sugar Cane Juice combo, nut allergy suffers are not "morally entitled" to a nut-free option and diabetics are not "morally entitled" to a sugar-free juice option. This applies whether the fast food store is a small family run business, or McDonalds.
To suggest that customers are "morally entitled" to a Samsung phone with zero tracking and zero telemetry is similarly absurd. If you don't like Samsung's product, don't buy it.
> If a fast food store decides to offer a Vietnamese Peanut Burger and Sugar Cane Juice combo, nut allergy suffers are not "morally entitled" to a nut-free option and diabetics are not "morally entitled" to a sugar-free juice option.
Why not? What gives McD the right to make such a decision unilaterally, other than might?
In fact, this is how disability legislation (for example) already tends to work. You don't get to tell disabled people to just go somewhere else, you have to make reasonable accomodations for them.
Apple's food scientists have verified the food safety of their new recipe, and they are sufficiently confident that nobody will suffer any allergic reaction. Nobody has disputed their assessment.
That doesn't stop consumers from engaging in Info Wars style paranoia, and grandstanding about the aforementioned paranoia.
You're seriously arguing that it's absurd for customers to have "absolute control" over all software?
No EU regulation could regulate away all "moral" concerns over software. More specifically, they EU could regulate, but the overwhelming majority of software companies would either strip significant features out for EU customers, or exit the market altogether.
The “moral entitlement” has nothing to do with this. The software is legally required to abide by its license agreement (which, by the way, you are supposed to have read, understood, and accepted prior to using said software).
I honestly can’t tell if you’re being sarcastic. A license grants the end user permission to use the software. It is not a series of obligations for how the software operates. This would be excruciatingly obvious if you read any software license.
A license agreement is, well, an agreement between the manufacturer and the consumer which may include a requirement to acknowledge certain aspects of how the software operates (e.g. the user may be required to agree to “share” some data).
Some commercial software licenses may include various disclaimers which exist to ward away litigious assholes. They only serve to protect the vendor against legal complaints, and do not impart responsibilities upon the vendor. Such disclaimers are not necessary but corporate lawyers have a raison d'être, and at a certain scale assholes become inevitable.
Notice is always good and Apple should implement notice.
However, "my data is being sent off my device" is incorrect, as GP explained. Metadata, derived from your data, with noise added to make it irreversible, is being sent off your device. It's the equivalent of sending an MD5 of your password somewhere; you may still object, but it is not factually correct to say your password was transmitted.
> It's the equivalent of sending an MD5 of your password somewhere; you may still object, but it is not factually correct to say your password was transmitted.
Hackers love to have MD5 checksums of passwords. They make it way easier to find the passwords in a brute force attack.
Nobody responding seriously to this because you seem to have missed the part where GP said "with noise added to make it irreversible" and the third sentence in that wikipedia article.
> However, "my data is being sent off my device" is incorrect, as GP explained. Metadata, derived from your data, with noise added to make it irreversible, is being sent off your device.
Sounds like my data is being sent off my device.
> It's the equivalent of sending an MD5 of your password somewhere
If the information being sent from my advice cannot be derived from anything other than my own data then it is my data. I don't care what pretty dress you put on it.
Well that's what you're told is happening. As it's all proprietary closed source software that you can't inspect or look at or verify in any manner, you have absolutely zero evidence whether that's what's actually happening or not.
"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.
I guess it depends on what you're calling "your data" -- without being able to reconstruct an image from a noised vector, can we say that that vector in any way represents "your data"? The way the process works, Apple makes their own data that leaves your device, but the photo never does.
It's the same as the CSAM initiative. It doesn't matter what they say they send, you cannot trust them to send what they say they send or trust them not to change it in the future.
Anything that leaves my devices should do so with my opt-IN permission.
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?
Do you consider your data to include non-reversible hashes of your data injected with random noise? I'm not sure I consider that my data. Its also not even really meta-data about my data.
I’m not the person you asked, but I agree with them. To answer your question: No, I do not use iCloud to store my photos. Even if I did, consent to store data is not the same as consent to scan or run checks on it. For a company whose messaging is all about user consent and privacy, that matters.
This would be easily solvable: On first run show a window with:
> Hey, we have this new cool feature that does X and is totally private because of Y [link to Learn More]
> Do you want to turn it on? You can change your mind later in Settings
In response to your question in the parent comment, no, I do not use iCloud. And I do not sync any of the things you mentioned here. If someone already consented to using iCloud to store their photos then I would not consider the service mentioned this post to be such a big issue, because Apple would already have the data on their servers with the user's consent.
edit: I will just add, even if we accept the argument that it's extremely secure and impossible to leak information, then where do we draw the line between "extremely secure" and "somewhat secure" and "not secure at all"? Should we trust Apple to make this decision for us?
> If someone already consented to using iCloud to store their photos then I would not consider the service mentioned this post to be such a big issue, because Apple would already have the data on their servers with the user's consent.
No, if you enable Advanced Data Protection for iCloud[1], the photos stored in Apple Photos are end to end encrypted.
I do not have anything backed up on any cloud servers on any provider. If I had to buy a new phone I would start from a fresh installation and move all of my data locally. It's not that I'm a "luddite", I just couldn't keep track of all of the different ways each cloud provider was managing my data, so I disabled all of them.
If only Apple had a centralized backup service that could store everything automatically at a click of a button so you wouldn’t have to juggle multiple cloud providers…
By one lone outlier who decides for “security” that the don’t want to support the platforms backup solution. That app purchase didn’t have to do anything besides store information locally in their sandbox
Apple IS just another cloud provider / centralized backup service. It's not fundamentally different than others, and if you're not in select group of whatever the respectful term is for those who stay strictly inside apple ecosystem, you will have multiple clouds and multiple data sets and multiple backups that all interact with each other and your heterogeneous devices in unpredictable ways. Icloud will not help you with that any more than google cloud or Samsung cloud etc. They all want to own all of your stuff, neither is simply a hyper helpful neutral director.
The “fundamental difference” is that it’s better integrated with your device and can backup the internal state of your device and the apps.
Even if you use Microsoft Office or GSuite and save using the standard file picker, you can save to iCloud. iCloud has a native app for Windows and plug ins on Windows to sync browser bookmarks for Chrome, Edge and Firefox
And the alternative people are proposing are four or five self hosted solutions?
Again, I think there's an assumption of single device / ecosystem loyalty in your statement? I have an android phone and iOS phone and three android tablets and a bunch of laptops with various operating systems.
Iphone is "just another device". I don't feel Icloud is any better integrated with my Samsung note, than google is integrated with my iPhone - in fact, the opposite. Google, for example, CAN sync my photos across iphone and Android and windows devices. Whereas my wife knows the primeval scream from the home office every 6 months I try to claw photos out of apple's greedy selfish hands :-)
For people who JUST use iphone, sure, Icloud is the boss just like for people who JUST use e.g. Samsung galaxy the Samsung cloud is awesome. But that's not a high bar. I feel we are still lacking empathy here for people like original poster who may have more than one device in their lives.
And none of these can sync your bookmarks, iOS settings or store the internal state of apps on your iPhone.
And I wouldn’t have the same arguments if they weee using Google cloud. But they are concerned about “privacy” and trust Google?
But my argument is about people thinking that Apple or Google should care about the minuscule number of people who are hosting their own syncing services
None of that is relevant to my point. You seem to be trying to catch people in some kind of gotcha instead of engaging honestly with the problem at hand. But alright, I’ll bite.
Yes, I always start with clean installs, both on iOS and on macOS. Sometimes I even restart fresh on the same device, as I make sure my hardware lasts. I don’t sync bookmarks, I keep them in Pinboard and none of them has any private or remotely identifiable information anyway. I don’t care about saving browser history either, in fact I have it set to periodically auto-clear, which is a feature in Safari.
No I am trying to say with a connected device using online services, the service provider is going to have access to your data that you use to interact with them.
To a first approximation, everyone in 2024 expects their data and settings to be transferred across devices.
People aren’t working as if it is 2010 when you had to backup and restore devices via iTunes. If I’m out of town somewhere and my phone gets lost, damaged or stolen, I can buy another iPhone, log into my account and everything gets restored as it was.
Just as I expect my watch progress to work when I use Netflix between my phone, iPad, Roku devices etc.
And that should rightfully be your informed choice. Just like everyone else should have the right to know what data their devices are sending before it happens and be given the informed choice to refuse. People shouldn’t have to learn that from a random blog post shared on a random website.
How many times are you going to shift the goalposts? This is getting tiresome, so I’ll make it my last reply.
I don’t have Netflix but neither is that relevant to the point, you’re obviously and embarrassingly grasping at straws.
No one is arguing against continuous cloud backups, they’re arguing about sending data without consent. Which, by the way, is something Apple used to understand not to do.
Apple’s OS are already filled with Windows Vista style popups and permissions for inconsequential crap, people have been making fun of them for that for years.
If you are doing continuous cloud backups and using Apple services - you are already giving Apple your data and your solution is to add even more permissions? You are not going to both use any Apple service that requires an online component and keep Apple from having your data.
Isn’t it bad enough that I have a popup every time I copy and paste between apps?
> Isn’t it bad enough that I have a popup every time I copy and paste between apps?
For me, not really no. It reminds me I am copying information and not from some phishing app, I find it informative.
And I'm probably one of the few who actually click "Reject" to the cookie pop ups having to click no on 3742 legitimate consents.
The simple answer is everything should be opt-out. I'll opt-in if I require it because frankly, regardless to how Fort-Knox my data is $CORP still cannot be trusted.
Strictly Signal via self-hosted VPN for messages. My email web client provided by my email server (Zimbra) which are hosted on colocated servers. 3cx for calls via self-hosted PBX.
Video conferencing instead of FaceTime are made via self-hosted Jitsi and if I am to brag all running on FreeBSD.
Out of Apple or Google I trust neither however will align with Apple more than Google. It's as close as I can get from not having data collected from mongrels.
Netflix being unable to know your watch history on their service is exactly the goal of homomorphic encryption. The technology to make that work at that scale does not exist, however for smaller bits of data, eg phone numbers, that's entirely possible!
With PIR, an Apple phone recieving a phone call queries Apple's database with that phone number, but because it's using homomorphic encryption, Apple doesn't know the number that called despite looking it up in their database to provide caller id info, so they can't tie your phone number and the callers phone number together.
As a general principle, I think computers should execute commands that users issue, and then wait for the next command. That's it.
Computers should not be sneakily doing things in the background without my commanding them to do so. But if they insist that the only way they can work is by doing things in the background, then I expect the computer to at the very least obtain my consent before doing those things. And computers should definitely not be exfiltrating anything over to the network without my explicit command to do so. This shit world we are living in where your computer just does whatever the application developer wants it to do rather than what the user wants it to do has to come to an end!
If you care about your “privacy” and no external service providers having access to your data - that means you can’t use iCloud - at all, any messages service, any back up service, use Plex and your own hosted media, not use a search engine, etc.
No what we need is for people to realize that no multi trillion dollar company is going to make life harder for 99.999% of their users because of a few outliers
How exactly is a new feature that is not advertised harder for you, or for anyone for that matter?
I bet most of those made up numbers of yours will have no idea that the feature exists.
A simple screen like they usually do with "Whats new in iOS" could easily have let you enabled it on the get go, with the additional benefit that you would have been made aware of it existing.
This iOS 18.2 update had no such screen, I just updated.
When your phone sends out a ping to search for cellular towers, real estate brokers collect all that information to track everywhere you go and which stores you visit.
Owning a phone is a privacy failure by default in the United States.
You are being downvoted because you're so painfully correct. It's not an issue exclusive to the United States, but American intelligence leads the field far-and-away on both legal and extralegal surveillance. The compliance forced by US Government agencies certainly helps make data tracking inescapable for the average American.
Unfortunately, the knee-jerk reaction of many defense industry pundits (and VCs, for that matter) is that US intelligence is an unparalleled moral good, and the virtues of privacy aren't worth hamstringing our government's work. Many of these people will try to suppress comments like yours because it embarrasses Americans and American business by association. And I sympathize completely - I'm dumbfounded by the response from my government now that we know China is hacking our telecom records.
You aren't wrong, but... it's odd coming here to HN and seeing people talk about privacy like we aren't in the nth generation of people trading theirs away for a pittance. I think the market for the sort of privacy envisioned by some here is incredibly small, incredibly niche, and honestly one of the least likely to buy an iPhone in the first place.
Most people broadcast their lives on social media, happily opt in to all sorts of schemes that track them just for minor conveniences. For people like that, the idea that the privacy protection outlined by the OP isn't enough rings really hollow.
Or to put it bluntly, at some point this really stops feeling like a practical debate, and more of an ideological one.
You're presenting a false dichotomy between "perfect user understanding" and "no user choice." The issue isn't whether users can fully comprehend homomorphic encryption or differential privacy – it's about basic consent and transparency.
Consider these points:
1. Users don't need a PhD to understand "This feature will send data about your photos to Apple's servers to enable better search."
2. The complexity of the privacy protections doesn't justify removing user choice. By that logic, we should never ask users about any technical feature.
3. Many privacy-conscious users follow a simple principle: they want control over what leaves their device, regardless of how it's protected.
The "it's too complex to explain" argument could justify any privacy-invasive default. Would you apply the same logic to, say, enabling location services by default because explaining GPS technology is too complex?
The real solution is simple: explain the feature in plain language, highlight the benefits, outline the privacy protections, and let users make their own choice. Apple already does this for many other features. "Default off with opt-in" is a core principle of privacy-respecting design, regardless of how robust the underlying protections are.
I don't believe I said or implied that anywhere: 'You're presenting a false dichotomy between "perfect user understanding" and "no user choice."'? Happy to be corrected if wrong.
Closest I come to presenting an opinion on the right way UX was "I'm not sure what the right call is here.". The thing I disagreed with was a technical statement "the only way to guarantee computing privacy is to not send data off the device.".
Privacy respecting design and tech is a passion of mine. I'm pointing out "user choice" gets hard as the techniques used for privacy exceed the understanding of users. Users can intuitively understand "send my location to Google [once/always]" without understanding GPS satellites. User's can't understand the difference between "send my photo" and "send homomorphicly encrypted locally differentially private vector of e=0.8" and "send differentially private vector of e=50". Your prompt "send data about your photos..." would allow for much less private designs than this. If we want to move beyond "ask the user then do it", we need to get into the nitty gritty details here. I'd love to see more tech like this in consumer products, where it's private when used, even when opted-in.
I appreciate your passion for privacy-respecting technology and your clarification. You make good points about the nuances of privacy-preserving techniques. However, I think we can separate two distinct issues:
1. The technical excellence of Apple's privacy protections (which you've explained well and seem robust)
2. The ethical question of enabling data transmission by default
Even with best-in-class privacy protections, the principle of user agency matters. A simplified prompt like "This feature will analyze your photos locally and send secure, anonymized data to Apple's servers to enable better search" would give users the basic choice while being technically accurate. The technical sophistication of the privacy measures, while commendable, doesn't override the need for informed consent.
This is not a matter of respect, it is a matter of ethics. Otherwise you will just end up rationalizating technocratic, unethical technology. No amount of passion will justify that.
The choice is between "use an online service" or "don't use an online service". That's simple enough for anyone to understand.
Apple can try to explain as best it can how user data is protected when they use the online service, and then the user makes a choice to either use the service or not.
In my case, I have don't even have a practical use for the new feature, so it's irrelevant how private the online service is. As it is, though, Apple silently forced me to use an online service that I never wanted.
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 functionality in return, but it can only be considered a regression in terms of privacy.
Sure, but if we follow that line of thinking to its logical conclusion, we must move to a cabin in the woods, 100 miles from the nearest civilization, growing our own food and never connecting our computing devices to anything resembling a network.
No? You can have a photos app that doesn't phone home while not having to move to a cabin in the woods. See: every photos app that doesn't phone home, and I currently don't live in a cabin in the woods.
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.
The line of thinking is right there: "not sending any info to anyone else anywhere at any time"
There are way more egregious privacy concerns than sending non-reversibly encrypted noisy photos to Apple. Why draw the line here and not the far worse things happening on your phone and computer right now?
The initiative is for the user to command their computer to communicate or not with the information of their choosing.
"Computer, I command thee to send this and only this information over the channel of my choosing, using following encryption scheme, for here be my seal of approval for anyone who might want to verify, and here be the key"
I understand the enthusiasm but from the business perspective it does not matter. Many businesses would fail if they go too deep on this. Their only audience would be people who are experts in the area. Other people are confused and disappointed since things are not working as they expect.
On Apple's scale, most people care about the things they can do, not about how it happens. For that reason, default matters when the option is only about the internal process pipeline and privacy.
As a result, it is enough to showcase that in case some expert investigates the matter, they show that privacy is considered in a reasonable level.
Maybe some day in the future these things are common knowledge, but I fear that the knowledge gap just increases.
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.
Trust in software will continue to erode until software stops treating end users and their data and resources (e.g. network connections) as the vendor's own playground. Local on-device data shouldn't be leaking out of radio interfaces unexpectedly, period. There should be a user intent tied to any feature where local data is sent out to the network.
So why didn't Apple just simply ask for user permission to enable this feature? My cynical opinion is because Apple knows some portion of users would instantly disallow this if prompted, but they feel they know better than those users. I don't like this attitude, and I suspect it is the same reason why there is an increasing discontent growing towards opt-out telemetry, too.