Hacker News Reader

Comment by derefr | Hacker News Reader

No, because this isn't about OS-level identifiers; it's about things like e.g. applications working together to track you by passing permacookies through Shared Containers; or about apps that ask for microphone privileges then listening for ultrasound beacons in retail stores to determine their location.

These are the sorts of prohibited behaviors that can be heuristically recognized by technical means (e.g. static analysis), but where any such recognition would necessarily result result in tons of false positives; and so those issues, when raised, must be passed to a team of human auditors for determination.

This is, by-and-large, why App Store submissions — even for updates — still require that human-auditor step. They're always watching for those seemingly-minor "this app got sold to someone evil" updates that slip in spyware — the kind you see often with Chrome Extensions.

View on HN

Your point is valid, but I think those examples are fixable. Permacookies could be fixed as simply as "Would you like to allow {EvilApp} to access data from {EvilPartnerApp}?", as there aren't a lot of reasons that apps should be passing data between each other without user consent (or the share sheet).

The second example has already been fixed with the microphone indicator from 1-2 versions back, where a light shows up in the corner whenever the microphone has been activated (and swiping down tells you what app activated it). A notification could be added if an app tried to activate the microphone when it wasn't in the foreground (but I don't think the OS lets you do that anyway?)

One other obvious "Turing-hard" spyware side-channel, is that it's basically up to the application developer to come up with a list of Internet domains it should be able to connect to, to put into the app's entitlements; and it's up to humans at Apple to determine whether that list is sane — often by starting up the app with syscalls to the network stack shimmed/traced, doing packet captures, and seeing what the app says to each of the domains it lists itself as entitled to talk to.

You'd think that maybe restricting connections to e.g. domains that are rooted in a zone the developer has proven ownership of, would be fine... but there are third-party advertising, analytics, and fingerprinting services that allow you to CNAME them as subdomains of your domain to evade ad-blocker signature recognition.

And, of course, no user could ever be expected to figure any of this out if asked in a prompt. "Example App is asking me to allow it to connect to abcdefg.example.com? Well, they own that, don't they? Why wouldn't I allow that?"

Asking the user sucks. All it does is train users to click yes without thinking about it because they just want to get on with their life. (See: The ubiquitous GDPR cookie prompts).

ANY "solution" that puts more burden on the user isn't.

They do it for location access, calendar access, notification access, and clipboard access for every app. Access to shared containers shouldn’t be a common occurrence outside of once when the app is set up.

You didn’t disprove what your parent said. People still just tap yes on them. I ran an experiment and put little snitch on my wife’s laptop. She just clicked “accept” every time it popped up without question.

Well, I'd love it if the GDPR consent prompts were anything like Apple's privacy prompts.

The problem with consent prompts on websites is that they are rarely in compliance with the GDPR.

The industry will always find ways around regulation. And what we’re left with is a confusing set of spaghetti laws.

They could just ask once for defaults not every time and have a per app dialog where the user could tweak the permissions, like browsers do. For instance I have almost everything blocked in the browser: camera, location etc.

Reply on news.ycombinator.com